As announced two weeks ago, with today’s releases of Flow 5.3.26, 6.0.23, 6.1.17 and 6.2.12 as well as Neos 4.3.19, 5.0.17, 5.1.13 and 5.2.6 those versions are going into security-only support phase. They will receive one more year of security fixes before they go EOL at the end of April 2022.
Be sure to upgrade your installations to Neos 5.3/Flow 6.3 minimum within this year.
Great job maintaining Flow / Neos! Thanks for that, and you are doing a great job communicating about it!
My question is about the need (or lack of) to maintain all those versions in the first place. In TYPO3 we decided from start that “minor versions” won’t be supported as soon as the “LTS” version is released. And in fact I don’t see the need to continue supporting 6.0, 6.1, 6.2 when there is a “6.3 LTS” already there.
I would open that question to debate if this could make the live of the core developers (and release managers) easier, because this is what we also decided back then with TYPO3 and got a good feedback for it - see also: https://typo3.org/cms/roadmap
Of course this gives a even bigger prominence to the “LTS Versions” (the intermediate versions were called “sprint releases”), but at the end aren’t these the “stable versions” that people are adopting for their “stable projects” anyway? Technically you then only need one branch per “major version”.
Hi @baschny
I, personally, support the way described by you, from the TYPO3 roadmap. The topic was raised by me in a Slack channel not so long ago, with no conclusion followed. I believe it’s a topic that is open to be discussed and where we can weight pros and cons
@baschny The only reason for maintaining those versions is that it is quite easy for us.
Since MRs go into the lowest maintained branch and those branches are upmerged until master is reached it is not much extra work. Just triggering the release job.
This also lead to the current situation where the lts and the following .0, .1 and .2 have the same end date. We have to upmerge anyways so we can also release aswell.
A really nice effect is that you do not gain any advantage from sticking to an old lts as the support end date is exactly the same as for the following versions until the next lts. That is why Neos is way less effected from the lts only agency sickness.
I understand the technical points, Martin, thanks for the feedback.
My concern was that “supporting” is more than just being able to “upmerge changes” and “doing the release”, but really have these old releases “available”, tested and awaiting bug reports. If someone now opens an issue and tells you “this happens in my 6.0 installation” you cannot tell the person to “first update to 6.3 LTS and then we talk about it”, you have to “support” it also (even if it might be already fixed in 6.1).
Sometimes bugs are not “code bugs” but conceptual bugs which could be fixed in the next minor version. You do not gain the benefit of dropping the support of the old version with this model.
As I understand this has not been a problem in the past, which is good, but maybe it happened due to the fact that its not so widespread as TYPO3 is. My comment was associated with the known fact that the “people” resources are limited and these should focus in solving issues in “newer” versions rather than in “older versions” - while still maintaining some sort of stability for people needing that (the “agency sickness” you mention).
I did not understand your last point. There is currently no benefit of sticking to “6.0” if “6.3 LTS” has the same end date, so this rises even more the question (to me) of why keep supporting it.
But there is need to do anything, just keep that in mind that there are other options also.
The advantage of the policy is that given the current timeline
If 5.3 had a longer support time than 7.0 or 7.1 many agencies would start new projects with that still. With our policy there is no gain in that and you are guaranteed to never have a disadvantage from using the recent Neos versions.
That is why in my experience whenever a new project is set up or receives a larger update the most recent Neos is used. In the meantime between larger works minor updates are installed until the project is on an LTS.
In the end most Neos Setups i know are running on quite recent versions which is good for us.
Thanks for the explanations Martin, I couldn’t have done it better 
I do see how if the project would have a much bigger user base and bug reports would pile in much more, we could have to constrain the support lifetime to reduce the amount of diverging code bases we need to look out for. Right now this is not an issue yet (well, it is in the form that we still are relatively slow with getting bugs fixed, but that’s not due to the amount of supported versions).
I do think there is one “gap” in our release schedule that we could discuss still, and that is the length of support for the versions. Right now the 2+1 year lifecycle together with our three releases per year leads to the effect that every then and when we have two LTS in active support and then (as happened with this) we suddenly fall back to only a single LTS. So this is a bit of a weird effect, but I’m not sure if it’s worth fixing and if so how that would be achieved. We’d need to lengthen the lifecycle by 4 months which would be odd.
Good point, I hadn’t thought about that side-effect, and it makes sense! So together with the understanding that it is currently no extra effort or resources required for that from the Neos Team, I would leave my comments only for the “Hinterkopf”.
You could plan the “LTS” releases in a fixed time frame (say march / september every 1.5 year) and then simply throw in the intermediate releases in between as it fits.
You could plan the “LTS” releases in a fixed time frame (say march / september every 1.5 year) and then simply throw in the intermediate releases in between as it fits.
Either that or we reschedule releases to one every half year, or reduce the minor versions to two (on top of the .0 major) and make the .2 the LTS… both would have roughly the same effect of having a fixed time of the year when a LTS is coming out.
PS:
There is currently no benefit of sticking to “6.0” if “6.3 LTS” has the same end date
That’s not quite correct. The x.3 / LTS is always the first release that will extend the support lifecycle of all following versions. So as Martin said, the point is you do not have a reason to stick to the older LTS because it is longer supported. Just upgrade to next major whenever it fits your schedule/resources, and upgrade to the next LTS (which should always be straightforward coming from the same major) to extend the active support of your running version 
PPS:
For reference the blog post where we introduced the current release schedule, with some more insights into the thoughts: