On Tue, Apr 26, 2022 at 5:57 AM Stefan Sperling <s...@elego.de> wrote: > > 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
The older policy seems simpler. One good takeaway from the new policy is that we give the expected lifespan of a release line to help admins plan server upgrades. It also helps us with our own planning. For example, at the time 1.14.x was released, Python 2 was still supported, but because we knew the expected lifespan of 1.14.x of 4 years would extend well after Python 2 went EOL, we were able to warn users, through our Release Notes, that while we would "try" to keep supporting Python 2 through the life of 1.14.x, we couldn't promise that and might have to drop that support if it became too burdensome. For reasons like this, declaring the expected lifespan as we've been doing since the new policy is helpful. We could keep the LTS vs Regular distinction because it standardizes on two possible lifespans, either 4 years or 6 months, BUT stop promising to make Regular releases, neither at 6 months nor any other frequency. It becomes optional to make a Regular release if and when it makes sense and the developers and community are willing and able make it happen. Regarding sponsors who would like to get features developed and released quickly, I think we should encourage it; at the same time, expectations need to be very clear: Since this is a volunteer community driven project, sponsors who would like to see quick releases need to take the initiative to make those releases happen, i.e., they need to include the release work in their allocation, not just the feature development itself. Sponsors who are willing to wait for volunteers to make a release are certainly free to do that too, as long as they understand that the release will happen only if and when volunteers step forward to do it. Setting those expectations clearly is A Good Thing for everyone. Back to Daniel's question: Since we aren't currently making a new LTS release every 2 years, I think it makes sense to go with what Stefan suggests, meaning EOL 1.10.x when 1.15.0 is released. At this time, we might warn that 1.10.x is "deprecated" (or something along those lines) by which I mean to warn users that 1.10.x will be EOL when the next minor release is made and encourage upgrading to 1.14.x as soon as reasonable. This means we could still make 1.10.x patch releases if it makes sense to do so, but admins should not count on that support continuing for any definable length of time. I know that seems kind of ad-hoc. It would be very helpful if we could as a community decide this policy question and then update the site. Cheers, Nathan
