I want to hear input from the community on a new release-cycle-model. I have some ideas that I think I great, but you can probably make them better
First off I want to redefine the different release types clearly so it’s easier to talk about the actual cycle.
We currently offer 4 types: Stable (when ready), Beta, Experimental, and Canary.
Unfortunately it’s more been a row of incredibly stable Canary builds and 3 nearly “Stable quality” beta and experimental releases.
I want to change that so that our definitions are:
Compiled master branch daily / weekly / whatever period is sensible for us
Must be released consistently even if barely any changes were made.
Should be automated so nobody has to spend time actively maintaining these releases.
No patch notes / possibly auto generated patch notes based on commit messages
Contains any new features that have not had issues reported after X canary releases, depending on the size of the feature.
All bug fixes are immediately released to this version for validation.
No specific feature or bug fix goals for each release, it just includes whatever meets the criteria on release day.
Compiled consistently every X canary build. A human needs to sit down and collect commits for this release, so it may not be entirely consistent.
Contains features with no issues reported after X experimental releases
Contains any bug fixes that have been in experimental for X releases
May have defined milestones if showstopper issues have been identified
Can be released whenever showstopper issues have been addressed as this more or less serves as stable until we reach 2.0 stable.
If the showstopper exists currently in the previous beta, new betas may still be released with bug fixes and stable features as long as new showstoppers are not introduced.
it just works
Will not be released until a stable milestone is reached
Has preferably existed as a beta but is now released as stable with little or no code changes.
There are a lot of X’es in here, because it’s hard to set intervals without knowing exactly how much it will take to put together the experimental and beta releases from the master branch. I had imagined something like:
- weekly canary release sunday night (it seems a lot of things are submitted/merged over the weekend)
- 2-3 weeks between experimental releases, depending on human factors and the complexity of new features added.
- 6-9 weeks between beta releases, giving time for 2-3 experimental releases which will allow time for both minor and major feature changes to make it into each release.
- Stable release end of year?
For this to work, and even be humanly possible to manage, we may need to implement some rules for tagging pull requests. I was thinking we, as best we can, try to tag every merged pull request with one of a list of options:
- [bug fix]
bug fixes make it straight into canary and experimental. Anything tagged [bug fix], that fixes an existing issue in Github, which isn’t a feature and doesn’t look too complicated, will make it into those releases right away.
Changes that are basically cosmetic, whether or not they have a relevant Github issue, can also be released right away to canary and experimental.
- [minor feature]
Implementations that are usually tweaks of existing code or very small amounts of code, which are easy to read and understand. These could make it into experimental releases after as little as 1 week of canary testing.
- [major feature]
Implementations that create completely new classes or rewrite larger parts of the code. Should be in a couple of canary builds before making it into experimental.
I volunteered to help Kenneth collect features and bugs for new releases, but I would like to have an interactive process for the human factor. I’d like to create a new topic for each experimental, beta, or stable version in #releases that lists all the features and bug fixes I intend to include. This will then be open for people to chime in with opinion and additions to the list before it’s released. Ideally the topic is created right away after a version was released so it can be discussed for the entire duration of a release cycle and allow people to focus on the upcoming features.
This ended up being a bit longer than I expected. I will edit updates into the original description here so that it will always serve as up to date information on release cycles.