On Mon, Apr 25, 2022 at 10:05:58PM +0200, Daniel Sahlberg wrote: > Hi, > > According to the Roadmap, How we plan releases[1], 1.10.0 is a LTS release > that will receive support for 4 years. According to the News archive[2], > 1.10.0 was released 2018-04-13. > > 1.10.0 was released approximately two months before the transition to the > LTS support policy and I have not been able to dig out what was promised > previously.
Before LTS releases, the 2 most recent lines of releases were supported. The most recent one would receive all types of bug fixes, the second one would receive security or data-corruption fixes only. I think it would make sense to go back to our old release policy. As far as I understand, the goal of the LTS policy was to publish releases more quickly to get features tested earlier by users and gather feedback before such features would be set in stone as part of an LTS release. This policy was invented at the same time as the shelving feature. I don't know for sure but I believe this feature and the involvement of a particular sponsor with some time-to-market constraints are part of the reason why a release policy change was suggested in the first place. The shelving feature was developed in multiple iterations and was shipped in several drafts, as planned. But it never made it beyond an experimental status, and given there has not been further development effort on this feature for quite some time I don't believe this will change. No other feature I am aware of has since adopted the development and release model which was introduced along with the shelving feature. The old release policy had its own share of problems. Essentially, every release was an LTS release, but the support time window for a release was not announced in advance. In practice, due to relatively slow pace of development, it worked out well (just look at the pacing of past release in the CHANGES file, it was not unreasonable). The most significant drawback of the old policy at the time was that the incentive to ship a release with features in early stages of development was very low. It was difficult to decide when the code on trunk was ready to be released. Every released feature had to be supported with full backwards compatibility going forward. This caused some friction, again with sponsors who had time-to-market constraints. The most prominent case occurred in the 1.5 cycle during which merge-tracking was developed (see here for an essay about this: http://www.hyrumwright.org/papers/floss2009.pdf). Ultimately, merge-tracking was shipped in a de-facto "experimental" state, and users were not all happy about this. Later releases had to correct several design-level problems and implementation bugs. Had the current LTS/non-LTS release split existed at that time, some of these issues might have been avoided before appearing as part of an LTS release and be supported forever. In any case, our current policy only works when it is actually implemented as intended, and this is not happening. In my opinion, our old release policy is more suited for the current state of things. Feature development does not need to be rushed, we don't have sponsors anymore who promise features to their clients and then come back to the project to ask about our progress on the next release. And our userbase seems to be more interested in a stable long-term support platform than in trying out experimental features. Going back to the old policy would mean that 1.10 would be supported until 1.15 comes out. At which point only 1.15 and 1.14 would be supported. Cheers, Stefan
