Hi all, Looks like we are moving forward and raising important points. Summing some key factors pointed in this discussion: - CloudStack is getting stable. - From the developers' side, the costs of releasing and maintaining an LTS are high. There is a "human" limitation in terms of how many releases the community can spin per year. - From the users' perspective, upgrading CloudStack infrastructures has its costs (Pierre also raised this and I totally agree). Many users end up upgrading their infra once a year (or once in 2 years).
With that said, I would like to propose the following: 1. The project compromises in having 1 LTS per year, and eventually one 1 Regular. For that, a roadmap would be defined to guide the community through the year. 2. It should be no problem to have an "extra" release in a specific year. For that, a volunteer would propose such release raising the reasons behind it. Each "extra" release proposed would require a VOTE. Please let me know if the proposed points look good. If that's the case, then I will move forward to present a draft to be added to the wiki. If you think it would be better to kick a separate VOTE thread for it I can also raise it. Regards, Gabriel. Em qui., 9 de set. de 2021 às 07:52, Rohit Yadav <rohit.ya...@shapeblue.com> escreveu: > 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. > > > > > > > > > > > > > > >
