Development Process

Draft/RFC

The long feature freeze currently required to stabilize the codebase before a release has an ill effect on the momentum of the development efforts as a whole. To alleviate this effect, I propose an altered development process that does away with the need for a feature freeze by branching the release off of the bleed branch before a release and then stabilizing that branch, while development can continue unhindered on the bleed branch.

Branches

The number and names of the currently existing branches will be kept under this proposal. The next branch, however, would serve a different role: instead of statically representing the state of the latest playtest, it would serve as the stabilization branch for the next release. That means that at the time when we would normally start the feature freeze, the current state of the bleed branch would be copied over to the next branch and tagged as the first playtest. Changes that are relevant for both bleed and next will be merged into bleed using the regular github workflow, and then cherry-picked manually for the next branch. Once the next branch is stable and ready for release, its state will be copied over to master.

Pull Requests

Pull requests will be opened against bleed as usual. Changes that will have to go into both bleed and next need to be tagged with the "Stable" label. Either the merging person or a dedicated one (to avoid "I thought you'd do it" type situations) should be tasked with keeping track of merged "stable" PRs and merging those into next. Changes that should only go to the stabilization branch should be opened directly against it.

Changelog

While the next branch is being stabilized, bleed will gain changes for which changelog entries will need to be written. Since the changelog is retrieved directly from the wiki during packaging, the changelog must not contain those entries that have been added to bleed. Therefore, a new changelog page is needed to which all changes that bleed accumulates get written. I propose Changelog-(bleed). Things that get merged into next will get written to the Changelog page by the merging person. Also, PRs that have been tagged with "Stable" must not be added to bleed's changelog, otherwise you run the risk of the change appearing in the changelog of two different versions.

Playtests

The first playtest in a cycle will probably coincide with the moment when next is reset to bleed's state. Further playtests will be tagged on next as it progresses.

Releases

At the time of release, the current state of next will be tagged and copied over to master. Both will remain in that state until the next feature freeze/playtest happens.

Side effects

• Testing effort will be split across two branches, and care should be given to decide if a fix is needed only for bleed or for next as well.
• There will no longer be a branch dedicated to pointing to the latest playtest.
• The tags for releases and playtests will no longer be found in bleed's history.
• The history of the master branch will likely only contain the playtest and release tags of the last cycle.
• Depending on the tested range, git bisect may work a bit differently when it needs to bisect across two branches. The first thing it asks the user for is to verify whether the commit where the two branches diverged is a good or a bad commit. After that, the bisect continues as normal.

       r_A                                      r_B                                  r_C
         |                                        |                                    |
master --o|                                       o|                                   o|
       r_A   pt_B1       pt_B2    pt_B2     r_B  /      pt_C1       pt_C2        r_C  /
         |   |               |        |       | /           |           |          | /
next   --o|  o---------------o--------o-------o|            o-----------o----------o|
            /                                              /
          /                                               /
bleed  --o-----------------------------------------------o-------------------------------------------->