Continuing the discussion from Creating a pull request:
Since a number of projects and companies rely on Neos and Flow now, we need to establish a more predictable and reliable release concept. The first point we need to agree upon is, if we commit to the concept of Semantic Versioning. Although I don’t see a real alternative, we should make sure that we agree on this.
We might have been negligent regarding Semantic Versioning in some cases in the past, but in my opinion that does not imply that we should or can squash it all together. We need to have clear rules related to this and form a group of people who look after its enforcement (that could be a “Quality Assurance Community of Practice”).
Predictability and Investment Protection
When someone starts using Neos for a new project, she usually wants to know for how long she can upgrade to new versions without having to invest into bigger refactorings of her site configuration or code. Especially bigger organisations with bigger projects need this kind of investment protection because a major upgrade could potentially mean a large invest.
If we follow Semantic Versioning, there is of course no point in releasing one major version after another without a reasonable amount of minor releases in between. That means we will have to take an extra look on changes which break backwards-compatibility. It is always annoying and demotivating if you worked on a bugfix or improvement and then, when it’s ready to be submitted as a Pull Request, the team mates refuse to merge it - for example because it contains breaking changes. Therefore we also need a better way to plan ahead for our own sake - if we know when the next major version is being scheduled, we can either postpone backwards incompatible features to a later version or maybe find a creative way to make the change compatible.
Here’s a proposal for a release cycle:
- we follow a simple and predictable scheme: 1.0, 1.1, 1.2, 1.3 (LTS), 2.0, 2.1, 2.2, 2.3 (LTS), 3.0, 3.1, 3.2, 3.3 (LTS) …
- from our experience so far, we need about half a year for one release; let’s just schedule versions according to it
- each major / minor release receives bug fixes for 1 year and security fixes for 1 additional year (2 in total)
- each Long Term Support version receives bug fixes for 2 years and security fixes for 1 additional year (3 in total)
- we might open a new major branch (e.g. 3.0) before the last minor version of a branch (2.3) is released in order to make larger refactorings and bigger features possible
In practical terms that could mean for Neos:
- 2.0: August 2015
- 2.1: December 2015
- 2.2: August 2016
- 2.3: December 2016
- 3.0: August 2017
Definition of Done / Definition of Breaking
We need to discuss and agree upon a Definition of Done (the prerequisite for merging a Pull Request, see also “Creating a Pull Request”) and that must contain a definition of when a change is considered “breaking”.
My take on the latter is the user’s point of view:
Every change in the core which requires an action by the user, integrator or developer which can’t be easily executed as an automated task during deployment is a breaking change.
According to that definition, code migrations are breaking, but database schema upgrades or node migrations (if they can really be executed during a deployment) are okay.
Side note: @kdambekalns found an interesting aspect in the versioning policy of PostgreSQL:
This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of application compatibility. In such cases, early retirement of a major version may be required.
So, what’s your take on all this?