Hi Gabriel, Agree with your conclusion - let's go with (at least) two major releases in a year.
I would add that there's no real logistical difference between a regular vs LTS release, so for example someone could propose and work on a "regular" release but it can become LTS if there are volunteers/contributors who want to maintain a release. That said - by all means just go ahead, propose and do release management! ps. And on a ".0" being stable I suppose it is somewhat stable in last few years as we've got our CI/CD systems quite robust for a subset of smoketests, all our releases thankfully at least go through a round of smoketests across three hypervisors - that is not to say no release has no reported issues (in fact they all do đ). Regards. ________________________________ From: Gabriel Bräscher <gabrasc...@gmail.com> Sent: Wednesday, September 8, 2021 18:39 To: dev <dev@cloudstack.apache.org> Subject: Re: [Discussion] Release Cycle Thanks all for helping with the discussion. Yes, Rohit. I need to answer a few pings, sorry for the delay :-) I totally agree with you and Paul, the costs of releasing are high, especially for the release manager(s) which dedicates a lot of energy and time to it. This is one of the reasons behind this discussion; when we formalize and document the release pace it is easier to plan a year knowing how things will roll out, from the perspective of RMs, devs, or users. Going in the same direction as Rohit, I also agree that we are getting each year stabler, maybe one LTS per year is better than the current pace of 2. Therefore, I would propose 1 LTS and 1 Regular per year; I see it as a good balance between stability and agility. Additionally, most users do not upgrade from an LTS to another twice a year, it takes time to plan and execute such tasks (and they always have some risks). From my experience, an LTS per year would perfectly match the needs of most users. I do understand that many adopt ".0" as an "unstable"/"Regular" LTS. However, I don't think this is the best approach. Additionally, many users do not see a ".0" LTS (which is how we brand in documentation, website, and release announcement) as a "Regular". I think that LTS, regardless of being the first spin or not, should be as stable as it can get. Having a Regular release could avoid the idea of ".0" not being a stable release. As an example, I've seen 4.12.0.0 (Regular) running in production with no issues regarding stability, while also bringing features that otherwise would be available only in 3-5 months. It was as stable as many ".0" LTS and I do believe that it also provided crucial feedback for the 4.13.0.0 (LTS). Regards, Gabriel. Em qua., 8 de set. de 2021 Ă s 04:58, Rohit Yadav <rohit.ya...@shapeblue.com> escreveu: > 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. > > > > > >
