A new release schedule

Last year in March, the Neos Team proudly presented its release plan and introduced Long-Term-Support (LTS) versions in order to improve reliablity and predictability of our development cycle. This was a major milestone and it was well recognized, as it targeted needs of customers and companies using Neos.

Our release plan currently consists of a LTS version once per year and three other minor versions per major, which boils down to one release once per quarter. We achieve this by developing against the least supported version branch, depending on whether the change is a Security fix, Bugfix, Task or a Feature. Then all changes are upmerged from lowest to highest branch and eventually end up in master. That way, all changes only have to be implemented for a single version branch and upmerging will take care to have the change applied to all later versions.

This works very well, but with our release plan, this would mean that we need to skip upmerges or at least skip tagging releases for versions that have run out of their support cycle. The first solution would introduce a lot of confusion and complicate our workflow unnecessarily, so that is not an option. The latter on the other hand, is something that does not cause a lot of work, since bugfix releases are pretty well automated already. We basically would just hold back bugfixes and security fixes that are already implemented for the versions following an LTS. This just creates artificial pressure to stay on LTS versions instead of upgrading to the next major version earlier unless your resources allow you to do regular updates anyway.

So why not just keep releasing bug and security fixes for the versions that get upmerged to anyway, effectively increasing the support cycle of those versions to that of the previous LTS?

So what does this actually mean?

• Our support cycle 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
• 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

This will mainly benefit smaller agencies and companies as well as freelancers, since they have more freedom to choose their point in time to do an upgrade.

After thinking about this I immediately brought it up in the team and got good feedback, eventually starting an official poll on discuss for all team members to take a decision, if we should change our release plan accordingly.

The vote was accepted with 88% and therefore our release schedule will be changed starting with the upcoming LTS sometime the next weeks!