I already started that idea in slack a while back (https://neos-project.slack.com/archives/C55K91JQJ/p1501874707514961) and want to formalize the idea and decision making on it here now.
What is it about?
We currently have a release cycle of LTS versions every fourth minor version. These versions are supposed to get an additional lifetime of bugfix and security fixes in order to provide a reliable version schedule for middle and bigger companies using our products.
This in turn means, that when for example Neos 3.0 / Flow 4.0 run out of bugfix support (Dec 2017), we would need to somehow only merge bugfixes into the Neos 2.3 / Flow 3.3 branches. Same goes for security fixes some time later.
However, our current code branching workflow is fully based on doing upmerges from the least supported version. So this means, that all bugfixes and security fixes that land in Neos 2.3 / Flow 3.3, will effectively also land in Neos 3.x / Flow 4.x as part of our normal workflow without any additional work. So what we would need to do to follow our release schedule, is skip doing releases for those versions when we do a release for the lower LTS version.
The work involved in actually tagging and releasing such bugfix releases, is however pretty well automated already (great job from the ops team there!), so the overhead of additional release versions is relatively small.
Therefore I raise the question: Why don’t we just promote all versions to the same support cycle as the highest previous LTS version?
What would that mean?
- Our release schedule will simplify quite noticeably (it will effectively be yearly jumps, but with small intermediary versions in between)
- There is less pressure for anyone to only upgrade to LTS versions and more freedom to also do upgrades in between, which especially helps small organizations with limited resources
- It therefore increases the time frame for doing major version upgrades, because there is no support lifecycle drawback in going to a major version earlier than the next LTS
- The need to upgrade to a higher version is mostly governed by new features available, i.e. added value in the product instead of fear of running out of bugfix/security support
- LTS versions therefore obviously lose their importance (which in turn means less responsibility/pressure on the release managers for those versions)
- less thinking for us (and our contributors!) on “which branch does this FIX need to go into?” - always the least supported LTS and there are max 2 at any time
- a bit more work in order to trigger releases and take care of for intermediary versions
- less thinking on for which versions to trigger a release for
The blue tones show which changes in the cycle would occur. The dark blue is added promised support we would deliver, the purplish blue tone are the security lifecycles that shift into bugfix support cycles. So effectively only two minor versions are affected by this change.
Overall I think we would reduce complexity from our own release flows and could promote this as an added benefit for the end users, especially small companies.
What are your opinions? Is this regarded as something good or do I overlook some negative effects? Please vote and/or leave your comment!
Should we adjust our release schedule?
- Yes, go with this new release cycle schedule
- No, keep the old release cycle schedule
- Abstain, I am undecided (need more info/don’t care)
0 voters
