Difference between revisions of "Contributing to Lorekeeper"

From Lorekeeper Wiki
Jump to navigation Jump to search
Line 1: Line 1:
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 [https://github.com/corowne/lorekeeper GitHub repository].
+
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 (or PRs) are always open at the [https://github.com/corowne/lorekeeper GitHub repository].
  
== General Architecture ==
+
==General Architecture==
 
Generally speaking, Lorekeeper and its branches are structured and maintained in keeping with [https://datasift.github.io/gitflow/IntroducingGitFlow.html GitFlow]. Loosely, this means that there are two persistent branches:  
 
Generally speaking, Lorekeeper and its branches are structured and maintained in keeping with [https://datasift.github.io/gitflow/IntroducingGitFlow.html GitFlow]. Loosely, this means that there are two persistent branches:  
  
Line 18: Line 18:
 
**These follow the naming scheme <code>release/UPCOMING-VERSION-HERE</code>.
 
**These follow the naming scheme <code>release/UPCOMING-VERSION-HERE</code>.
 
**These are created by a maintainer of the repo when an upcoming release is feature-complete or otherwise ready, and are branched off of <u>develop</u>.
 
**These are created by a maintainer of the repo when an upcoming release is feature-complete or otherwise ready, and are branched off of <u>develop</u>.
**Once they are created, '''no additional features will be merged into these branches''', only bugfixes for the features already in them.
+
**Once they are created, '''no additional features or work from <u>develop</u> 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 <u>develop</u> to incorporate 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 <u>develop</u> to incorporate them.
 
**In essence, the purpose of a release branch is to isolate, test, and if necessary fix a static set of features.
 
**In essence, the purpose of a release branch is to isolate, test, and if necessary fix a static set of features.
Line 30: Line 30:
 
**In such an event, <u>master</u> is merged back into <u>develop</u> as well to incorporate fixes.
 
**In such an event, <u>master</u> is merged back into <u>develop</u> as well to incorporate fixes.
  
== Branching Off ==
+
==Branching Off==
 +
In summary:
 +
 
 +
* When contributing to Lorekeeper, you will create either a feature or (more rarely) a hotfix branch.
 +
* If you are creating a new feature, it '''must be isolated in its own feature branch''' and a PRed into <u>develop</u>.
 +
*
  
 
*
 
*

Revision as of 12:24, 6 May 2021

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 (or PRs) 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 or work from develop 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.

Branching Off

In summary:

  • When contributing to Lorekeeper, you will create either a feature or (more rarely) a hotfix branch.
  • If you are creating a new feature, it must be isolated in its own feature branch and a PRed into develop.