Gabriel, all, I suppose it depends, there's no right answer just trade-offs. Here's my lengthy brain dump;
0. our LTS definition is really to tag a set of releases and show intent that they are "stable" and will be supported and get maintenance releases. We don't really do LTS releases like larger projects whose support lasts multi-years (3-5yrs, sometimes 7-10yrs). Fundamentally all our major .0 releases are just regular releases, with really the minor/maintenance releases making them stable or LTS-que. I like what Pierre-Luc is suggesting, but then say a 2-year "LTS" release means users don't get to consume features as they would only use "LTS" releases and wait for 2 years which may not be acceptable trade-off. 1. so if we leave what makes a release regular vs LTS for a moment, the important question is - do our *users* really want releases in production that may be potentially buggy with possibly no stablised releases (i.e. minor releases)? Most serious users won't/don't really install/upgrade the .0 release in production but wait for a .1 or above release, maybe in their test environments first - this is true for most of IT industry, not specific to CloudStack. 2. a typical major release effort would allow for at least a month of dev before freeze, then another month or two for stabilisation with multiple RCs, tests/smoketest/upgrade tests, getting people to participate, votes and wrap up the release do post-release docs/packages/announcements/websites etc; so speaking from experience and burnt hands a major release can eat up 2-3 months of bandwidth easily irrespective of what we call it (regular or LTS). If the development freeze is done for at least a month, you can theoretically do 12 major releases in a year but you would end up having intersecting release cycles and overlaps - you would also need a dedicated release team. One major release may be too less in a year for project's health, two in a year is what we're currently sort of trying (usually Q1/Q2 has a major release, and Q3/Q4 has another). Three is possible - maybe? But I think four would be just pushing it with people's time/bandwidth/focus eaten by release work than dev work. 3. the *main* issue is practicality and feasibility which Paul has mentioned too - do we've time, resources, and bandwidth to do multiple major releases, especially when we struggle to get the community to collaborate on issues and PRs (I'm looking at you Gabriel not responding to my comment for days and weeks sometimes đ - we all do it don't we đ) and then participate, test, and vote for releases when RCs are cut. 4. all said ^^ we do have an inclination to move fast break things and try things, and for this we do now have nightlies or daily snapshot builds for people to try out features/things without waiting for formal releases (but without the promise of upgrade paths) - http://download.cloudstack.org/testing/nightly/ 5. finally - I would say if you or anyone wants to work on a release (call it whatever, regular, LTS) - just propose and do! Regards. ________________________________ From: Daniel Augusto Veronezi Salvador <dvsalvador...@gmail.com> Sent: Tuesday, September 7, 2021 22:07 To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> Subject: Re: [Discussion] Release Cycle Hi Gabriel, thanks for opening this discussion. I'm +1 on it. My considerations: - We've to put a lot of efforts to support 3+ LTS simultaneously, which doesn't make sense. Regular versions will give us some breath and will reduce rework. - Although the EOL is well defined, it seems we don't have a solid criteria to define new versions, because they don't have a pattern. Users don't know when they will have a new version. Also, we don't have much planning to do the implementations. - We've been seeing Ubuntu life-cycle working for a long time, and we know it works well. It's a good reference to follow, we will not need to reinvent the wheel. Best regards, Daniel. On 31/08/2021 14:44, Gabriel Bräscher wrote: > Hello, > > I would like to open a discussion regarding the project release cycle. More > specifically on the following topics: > > 1. LTS and Regular releases > > 2. Releases period > > 3. Enhance roadmap and Release cycle for users > > #### 1 LTS and Regular releases > > It has been a while since the last regular release. Nowadays there are only > LTS releases; maybe we should get back to having regular versions in > between LTS. > > With a âRegularâ release users would be able to trade stability for new > features. Additionally, developers and users would have a âpilotâ of the > next LTS which could anticipate issues and result in a stable long-term > release. > > Please, let me know what you think of this. Should we get back to releasing > Regular releases in between LTS releases? > > For reference, here follow the past releases: > > +---------+---------+--------------+-------------+ > | Release | Type | Release date | EOL | > +---------+---------+--------------+-------------+ > | 4.15 | LTS | 19 Jan 2021 | 1 July 2022 | > +---------+---------+--------------+-------------+ > | 4.14 | LTS | 26 May 2020 | 1 Jan 2022 | > +---------+---------+--------------+-------------+ > | 4.13 | LTS | 24 Sep. 2019 | 1 May 2021 | > +---------+---------+--------------+-------------+ > | 4.12 | Regular | 4 April 2019 | N/A | > +---------+---------+--------------+-------------+ > | 4.11 | LTS | 12 Feb. 2018 | 1 July 2019 | > +---------+---------+--------------+-------------+ > | 4.10 | Regular | 6 July 2017 | N/A | > +---------+---------+--------------+-------------+ > | 4.9 | LTS | 25 July 2016 | 1 July 2018 | > +---------+---------+--------------+-------------+ > > #### 2 Releases period > > > We had in the past a new LTS per year. Then, we got into two new LTS per > year. This led from having 2 LTS maintained at the same time to 3. > With that said, I think this is neither documented nor has it been > discussed in the ML. > > We have the LTS minimum and maximum support dates well defined, but so far > there is no definition/guidelines towards the release period. > I would like to open this discussion so we can update the CloudStack wiki > page [https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS] and have > a clear definition of when the community should expect each release. > > #### 3 Enhance roadmap and Release cycle for users > > This topic is an extension of Topic 2. Once we have âTopic 2â well defined > we will be able to present a draft of future releases. > > The main idea of this email is to look for project stability and > predictability with a release cycle/roadmap similar to what is done by > Ubuntu [https://ubuntu.com/about/release-cycle]. > We would then be able to give users and developers a roadmap to look after. > I would also suggest such a release cycle to be presented on the website, > in addition to the âcwikiâ page [ > https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS]. > > Please let me know what you think. > > Best regards, > Gabriel. >
