Re: [Discussion] Release Cycle
unity > 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 > Sent: 10 September 2021 14:15 > To: dev > 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 > > Sent: Wednesday, September 8, 2021 18:39 > > To: dev > > 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
RE: [Discussion] Release Cycle
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 Sent: 10 September 2021 14:15 To: dev 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 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 > Sent: Wednesday, September 8, 2021 18:39 > To: dev > 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
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 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 > Sent: Wednesday, September 8, 2021 18:39 > To: dev > 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). Fundame
Re: [Discussion] Release Cycle
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 Sent: Wednesday, September 8, 2021 18:39 To: dev 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 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 &
Re: [Discussion] Release Cycle
lds 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 > Sent: Tuesday, September 7, 2021 22:07 > To: 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. > > > > > >
Re: [Discussion] Release Cycle
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 Sent: Tuesday, September 7, 2021 22:07 To: 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
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.
RE: [Discussion] Release Cycle
I think this discussion is a useful. BUT... Producing releases takes considerable effort and saying that we want a release every x months is all well and good, but historically there haven't been many people stepping up to coordinate them or do the spade work to close issues. So, in tandem with a conversation regarding how often the community would like to see releases, needs to be "is 'the community' going to pull together to make it happen?" Kind regards Paul Angus -Original Message- From: Pierre-Luc Dion Sent: Thursday, September 2, 2021 1:37 PM To: dev Subject: Re: [Discussion] Release Cycle I like the notion of LTS every 2 years and having 1 or 2 regular releases per year, like the Ubuntu model. Typically, upgrading our cloud from a major release is a big level of effort, especially around QA to make sure the upgrade does not affect customers. So, having to jump between LTS every year or so could be challenging. I'd be curious to know about other users' upgrade cycles. On Wed, Sep 1, 2021 at 1:11 AM David Jumani wrote: > Hi Gabriel, > > > 1. I'm a +1 on having regular releases between LTS ones and the > reasoning behind it. While stability is great, it will also be nice to > have a "pilot" as you mentioned which the community can test and > issues are resolved in the following LTS, rather than waiting for 2 - > 3 releases to get something allegedly stable in, which could still > have issues reported by users. > 2. I'm for having 1 Regular release (Mar-Apr) followed by an LTS > one > (~6 months down the line) each year. Wrt the LTS releases, they should > be supported for 1.5 to 2 years (at least 6 months after the following > LTS is out). If that might be too much then a single alternating > release annually around the same dates > 3. No strong opinion on this but it does seem like a good idea, but > not sure how religiously people will update the new page with every > feature they intend to add and follow up on it > > ____________ > From: Gabriel Bräscher > Sent: Tuesday, August 31, 2021 11:14 PM > To: dev > Subject: [Discussion] Release Cycle > > 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 “
Re: [Discussion] Release Cycle
I like the notion of LTS every 2 years and having 1 or 2 regular releases per year, like the Ubuntu model. Typically, upgrading our cloud from a major release is a big level of effort, especially around QA to make sure the upgrade does not affect customers. So, having to jump between LTS every year or so could be challenging. I'd be curious to know about other users' upgrade cycles. On Wed, Sep 1, 2021 at 1:11 AM David Jumani wrote: > Hi Gabriel, > > > 1. I'm a +1 on having regular releases between LTS ones and the > reasoning behind it. While stability is great, it will also be nice to have > a "pilot" as you mentioned which the community can test and issues are > resolved in the following LTS, rather than waiting for 2 - 3 releases to > get something allegedly stable in, which could still have issues reported > by users. > 2. I'm for having 1 Regular release (Mar-Apr) followed by an LTS one > (~6 months down the line) each year. Wrt the LTS releases, they should be > supported for 1.5 to 2 years (at least 6 months after the following LTS is > out). If that might be too much then a single alternating release annually > around the same dates > 3. No strong opinion on this but it does seem like a good idea, but not > sure how religiously people will update the new page with every feature > they intend to add and follow up on it > > > From: Gabriel Bräscher > Sent: Tuesday, August 31, 2021 11:14 PM > To: dev > Subject: [Discussion] Release Cycle > > 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. > > > >
Re: [Discussion] Release Cycle
Hi Gabriel, 1. I'm a +1 on having regular releases between LTS ones and the reasoning behind it. While stability is great, it will also be nice to have a "pilot" as you mentioned which the community can test and issues are resolved in the following LTS, rather than waiting for 2 - 3 releases to get something allegedly stable in, which could still have issues reported by users. 2. I'm for having 1 Regular release (Mar-Apr) followed by an LTS one (~6 months down the line) each year. Wrt the LTS releases, they should be supported for 1.5 to 2 years (at least 6 months after the following LTS is out). If that might be too much then a single alternating release annually around the same dates 3. No strong opinion on this but it does seem like a good idea, but not sure how religiously people will update the new page with every feature they intend to add and follow up on it From: Gabriel Bräscher Sent: Tuesday, August 31, 2021 11:14 PM To: dev Subject: [Discussion] Release Cycle 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.
[Discussion] Release Cycle
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.
