Contributing to Lorekeeper

Lorekeeper, much like any project in its vein, thrives on community contributions; be they bugfixes, new features, extensions, or so on, these efforts are what help make the project shine. If you are interested in contributing to core Lorekeeper, pull requests are always open at the GitHub repository.

General Architecture

Generally speaking, Lorekeeper and its branches are structured and maintained in keeping with GitFlow. Loosely, this means that there are two persistent branches:

• The default/primary branch-- master, in this case-- which always contains the current release, and
• The development branch-- develop, in this case-- which always contains the latest work-- features, fixes, and so on.
  • This branch is itself off of master and in the infrequent but possible event that the latter is updated directly (i.e. via a hotfix), master will be merged into it.

As well as three types of branches; each branch of these types is destined to be merged into another and is important but ultimately impermanent:

• Feature branches
  • These follow the naming scheme feature/FEATURE-NAME-HERE, i.e. feature/two-factor-auth.
  • While these are called feature branches, they can contain new features and/or non-emergency bugfixes!
  • New features are always merged into develop and develop only.
  • These branches are created branched off of develop (if they contain features or there is no current release branch) or the current release branch (if there is one, and the feature branch contains only bugfixes for the current content within it).
• Release branches
  • These follow the naming scheme release/UPCOMING-VERSION-HERE.
  • These are created by a maintainer of the repo when an upcoming release is feature-complete or otherwise ready, and are branched off of develop.
  • Once they are created, no additional features will be merged into these branches, only bugfixes for the features already in them.
  • Conversely, bugfixes for features contained in a release branch are merged directly into the release branch and the release branch only. In the event that a release branch receives bugfixes, said release branch is periodically merged back into develop to incorporate them.
  • In essence, the purpose of a release branch is to isolate, test, and if necessary fix a static set of features.
  • When a release branch is sufficiently stable and any necessary preparations complete, the branch will be merged into master and become the new current release.
• Hotfix branches
  • These follow the naming scheme hotfix/HOTFIX-NAME-HERE.
  • These contain emergency bugfixes, e.g. fixes for critical issues or security vulnerabilities.
  • These are directly branched off of master/the current release and merged back into master when complete.
  • In such an event, master is merged back into develop as well to incorporate fixes.