Gabriel, FYI point 2 is covered in the community bylaws (Section 3.4.3)
3.4.3. Release Plan - Defines the timetable and work items for a release. The plan also nominates a Release Manager. - A lazy majority of active committers is required for approval. - Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. On point 1, "...a roadmap would be defined to guide the community through the year." Is this something ridged or a fluid list of things people think they'll be putting in as they go along? Also, you haven't covered WHO is doing these releases that the community is committing to. Otherwise a +1 means that the voter was committing themselves to working on the release. 3.1.2. Voting may take four flavors: 3.1.2.1. +1 "Yes," "Agree," or "the action should be performed." In general, this vote also indicates a willingness on the behalf of the voter in "making it happen" .... http://cloudstack.apache.org/bylaws.html Kind regards Paul Angus -----Original Message----- From: Gabriel Bräscher <gabrasc...@gmail.com> Sent: 10 September 2021 14:15 To: dev <dev@cloudstack.apache.org> Subject: Re: [Discussion] Release Cycle 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. > > > > > > > > > > > > > > >
