-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Development Process
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. Nonetheless those should be tagged with the "Stable" label as well.
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-------------------------------------------->
Players ๐ฒ
- FAQ โ
- Installation ๐ฆ
- Game Content ๐ฟ
- Hotkeys and Stances ๐ฎ
- Strategies ๐
- Settings ๐ง
- Dedicated Server โพ
- RaspberryPi ๐
- Badges & Icons ๐ฅ
- Changelog ๐
Modders โ๏ธ
- Audio guide ๐
- Traits ๐
- Palettes and Remaps ๐จ
- World Coordinate System ๐
- Map scripting
- Lua-API ๐
- Conditions ๐
- Mapping ๐ง
- Pixelart ๐
Developers ๐ง
- Contributing โค๏ธ
- Compiling
- Hacking
- Coding Standard ๐
- Branches and Releases ๐
- Release Checklist โ
- Sequences
- Glossary
- Reverse engineering ๐
- License ยฉ๏ธ