Thanks for raising the bylaws, Paul. You are absolutely right regarding point 2 being covered by 3.4.3 bylaws. That's the idea indeed; keep the "extra" release aligned with the current release plan. Therefore, we would still hold the flexibility for having more releases if that fits the community's desire. Combined with a "fixed" release.
To make it clear, this discussion's main goal is to find what would be the ideal release period for the project (if there is any ideal), as well as the LTS vs Regular topic. "Point 1" would be added into the bylaws, and then "point 2", as you correctly addressed, would keep the current bylaws. It would just need to be updated with regards to being an "extra" release. Considering the fact that the project is already releasing at least 1 LTS per year -- and even releasing 2 LTSs/year in some cases -- I don't see why not doing such formalization/bylaw changes. We could also create a "point 3" which would cover a case where there is no need in releasing a new LTS in the year, which I doubt will happen anytime soon. Such a case would require a discussion/vote in order to cancel the LTS of the year. #### Release roadmap I notice that there are some doubts regarding this topic. Sorry for not making myself clear with regard to this topic. > 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? The proposal is to not be too rigid, and it would not cover features nor bug fixes but mainly the releases themselves (4.15, 4.16, 4.X ... 5.0,...). As an example, we could define the following: - LTS Begin of Q4 - 20XY: Raise a discussion looking for volunteers for the next LTS End of Q4 - 20XY: the volunteer RM proposes freeze dates and is already working towards the release process Q1 - 20XY+1: branch is in the freeze state, RCs will be raised for a vote Q1/Q2 - 20XY+1: LTS is released when passes on RC vote - Regular Begin of Q2 - 20XY+1: Raise a discussion looking for volunteers for the next Regular End of Q2 - 20XY+1: RM proposes freeze dates and is already working towards the release Q3 - 20XY+1: branch is in the frozen state, RCs will be raised for a vote Q3/Q4 - 20XY+1: LTS is released when passes on RC vote - LTS maintenance (X.Y.0.0, X.Y.1.0, ...) For the LTS maintenance releases, it would stay as currently. Someone volunteers at any time following "3.4.3. Release Plan" and "3.4.4. Product Release". As an example for Releases roadmap to be presented for users: +---------+---------+--------------+-------------+ | Release | Type | Release date | EOL | +---------+---------+--------------+-------------+ | Y.C | Regular | Q3 - 2023 | N/A | <- we can go up to a reasonable future date and update with the time (1,2 years) +---------+---------+--------------+-------------+ | Y.B | LTS | Q1 - 2023 | Q1 - 2024 | +---------+---------+--------------+-------------+ | Y.A | Regular | Q3 - 2022 | N/A | +---------+---------+--------------+-------------+ | X.B | LTS | Q1 - 2022 | Q1 - 2023 | +---------+---------+--------------+-------------+ | X.A | Regular | Q3 - 2022 | N/A | +---------+---------+--------------+-------------+ | 4.16 | LTS | Q4 - 2021 | Q4 - 2022 | <- to be released, so we have a plan with the quarter and year +---------+---------+--------------+-------------+ | 4.15 | LTS | 19 Jan 2021 | 1 July 2022 | <- released, so we have the exact date of release and EOL +---------+---------+--------------+-------------+ | 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 | +---------+---------+--------------+-------------+ Regards, Gabriel. Em sáb., 11 de set. de 2021 às 17:26, Paul Angus <p...@angus.uk.com.invalid> escreveu: > 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. > > > > > > > > > > > > > > > > > > > > > > > > >
