You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Gabriel Bräscher <ga...@gmail.com> on 2021/08/31 17:44:41 UTC
[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
Posted by pa...@apache.org.
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 <pd...@apache.org>
Sent: Thursday, September 2, 2021 1:37 PM
To: dev <de...@cloudstack.apache.org>
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 <Da...@shapeblue.com>
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 <ga...@gmail.com>
> Sent: Tuesday, August 31, 2021 11:14 PM
> To: dev <de...@cloudstack.apache.org>
> 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
Posted by Pierre-Luc Dion <pd...@apache.org>.
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 <Da...@shapeblue.com>
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 <ga...@gmail.com>
> Sent: Tuesday, August 31, 2021 11:14 PM
> To: dev <de...@cloudstack.apache.org>
> 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
Posted by David Jumani <Da...@shapeblue.com>.
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 <ga...@gmail.com>
Sent: Tuesday, August 31, 2021 11:14 PM
To: dev <de...@cloudstack.apache.org>
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
Posted by Gabriel Bräscher <ga...@gmail.com>.
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 <pa...@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 <ga...@gmail.com>
> Sent: 10 September 2021 14:15
> To: dev <de...@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.yadav@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 <ga...@gmail.com>
> > Sent: Wednesday, September 8, 2021 18:39
> > To: dev <de...@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.yadav@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 <dv...@gmail.com>
> > > Sent: Tuesday, September 7, 2021 22:07
> > > To: dev@cloudstack.apache.org <de...@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
Posted by Paul Angus <pa...@angus.uk.com.INVALID>.
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 <ga...@gmail.com>
Sent: 10 September 2021 14:15
To: dev <de...@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 <ro...@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 <ga...@gmail.com>
> Sent: Wednesday, September 8, 2021 18:39
> To: dev <de...@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.yadav@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 <dv...@gmail.com>
> > Sent: Tuesday, September 7, 2021 22:07
> > To: dev@cloudstack.apache.org <de...@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
Posted by Gabriel Bräscher <ga...@gmail.com>.
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 <ro...@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 <ga...@gmail.com>
> Sent: Wednesday, September 8, 2021 18:39
> To: dev <de...@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.yadav@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 <dv...@gmail.com>
> > Sent: Tuesday, September 7, 2021 22:07
> > To: dev@cloudstack.apache.org <de...@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
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <ga...@gmail.com>
Sent: Wednesday, September 8, 2021 18:39
To: dev <de...@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 <ro...@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 <dv...@gmail.com>
> Sent: Tuesday, September 7, 2021 22:07
> To: dev@cloudstack.apache.org <de...@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
Posted by Gabriel Bräscher <ga...@gmail.com>.
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 <ro...@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 <dv...@gmail.com>
> Sent: Tuesday, September 7, 2021 22:07
> To: dev@cloudstack.apache.org <de...@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
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <dv...@gmail.com>
Sent: Tuesday, September 7, 2021 22:07
To: dev@cloudstack.apache.org <de...@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
Posted by Daniel Augusto Veronezi Salvador <dv...@gmail.com>.
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.
>