You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Daan Hoogland <da...@gmail.com> on 2024/02/19 12:49:51 UTC
[VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning
scheme. The result would be that the next major version will be 20
instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
and the versions are processed numerically there are no technical
impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Wido den Hollander <wi...@widodh.nl.INVALID>.
+1
Op 19/02/2024 om 13:49 schreef Daan Hoogland:
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
> counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning
> scheme. The result would be that the next major version will be 20
> instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
> and the versions are processed numerically there are no technical
> impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
Re: [VOTE] next version 20 instead of 4.20
Posted by Nicolas Vazquez <Ni...@shapeblue.com>.
+1
Regards,
Nicolas Vazquez
From: Daan Hoogland <da...@gmail.com>
Date: Monday, 19 February 2024 at 09:50
To: dev <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Subject: [VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning
scheme. The result would be that the next major version will be 20
instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
and the versions are processed numerically there are no technical
impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Wido den Hollander <wi...@widodh.nl.INVALID>.
+1
Op 19/02/2024 om 13:49 schreef Daan Hoogland:
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
> counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning
> scheme. The result would be that the next major version will be 20
> instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
> and the versions are processed numerically there are no technical
> impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
RE: [VOTE] next version 20 instead of 4.20
Posted by Alex Mattioli <Al...@shapeblue.com>.
+1
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Monday, February 19, 2024 1:50 PM
To: dev <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Subject: [VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Rohit Yadav <ro...@shapeblue.com>.
+1
Regards.
________________________________
From: me@swen.io <me...@swen.io>
Sent: Monday, February 19, 2024 18:29
To: 'dev' <de...@cloudstack.apache.org>
Subject: AW: [VOTE] next version 20 instead of 4.20
+1
-----Ursprüngliche Nachricht-----
Von: Daan Hoogland <da...@gmail.com>
Gesendet: Montag, 19. Februar 2024 13:50
An: dev <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Betreff: [VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
AW: [VOTE] next version 20 instead of 4.20
Posted by me...@swen.io.
+1
-----Ursprüngliche Nachricht-----
Von: Daan Hoogland <da...@gmail.com>
Gesendet: Montag, 19. Februar 2024 13:50
An: dev <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Betreff: [VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Nux <nu...@li.nux.ro>.
+1
On 2024-02-19 15:09, Andrija Panic wrote:
> +1
>
> On Mon, 19 Feb 2024 at 13:50, Daan Hoogland <da...@gmail.com>
> wrote:
>
>> LS,
>>
>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
>> counted please reply to dev@.
>>
>> As discussed in [1] we are deciding to drop the 4 from our versioning
>> scheme. The result would be that the next major version will be 20
>> instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
>> and the versions are processed numerically there are no technical
>> impediments.
>>
>> +1 agree (next major version as 20
>> 0 (no opinion)
>> -1 disagree (keep 4.20 as the next version, give a reason)
>>
>> As this is a lazy consensus vote any -1 should be accompanied with a
>> reason.
>>
>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>>
>> --
>> Daan
>>
Re: [VOTE] next version 20 instead of 4.20
Posted by Nux <nu...@li.nux.ro>.
+1
On 2024-02-19 15:09, Andrija Panic wrote:
> +1
>
> On Mon, 19 Feb 2024 at 13:50, Daan Hoogland <da...@gmail.com>
> wrote:
>
>> LS,
>>
>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
>> counted please reply to dev@.
>>
>> As discussed in [1] we are deciding to drop the 4 from our versioning
>> scheme. The result would be that the next major version will be 20
>> instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
>> and the versions are processed numerically there are no technical
>> impediments.
>>
>> +1 agree (next major version as 20
>> 0 (no opinion)
>> -1 disagree (keep 4.20 as the next version, give a reason)
>>
>> As this is a lazy consensus vote any -1 should be accompanied with a
>> reason.
>>
>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>>
>> --
>> Daan
>>
Re: [VOTE] next version 20 instead of 4.20
Posted by Andrija Panic <an...@gmail.com>.
+1
On Mon, 19 Feb 2024 at 13:50, Daan Hoogland <da...@gmail.com> wrote:
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
> counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning
> scheme. The result would be that the next major version will be 20
> instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
> and the versions are processed numerically there are no technical
> impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a
> reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
> --
> Daan
>
--
Andrija Panić
RE: [VOTE] next version 20 instead of 4.20
Posted by Alex Mattioli <Al...@shapeblue.com>.
+1
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Monday, February 19, 2024 1:50 PM
To: dev <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Subject: [VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Daan Hoogland <da...@gmail.com>.
Paul,
On Mon, Feb 19, 2024 at 6:21 PM Paul Angus <pa...@angus.uk.com.invalid> wrote:
>
> Hi Daan,
>
> Can you clarify what we are actually voting on please.
>
> In thread that is linked I've seen:
>
> "[the vote] will be to adjust to the semantic versioning system."
> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
We are using a crooked semantic versioning system and that is entirely
due to maintaining the 4 in our versioning scheme. We have been
changing and adding major features on updating the second number (20
to be). We have been using the third number for bug fixes and minor
enhancements. And we have been using the fourth number for emergency
security fixes.
So we are not maintaining semantic versioning but going to semantic
versioning by repairing our system of versioning. You could say this
is a minor bugfix.
>
> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
Yes, exactly. Except for dropping the 4, nothing will change.
>
> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>
>
> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>
>
>
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>
> -----Original Message-----
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, February 19, 2024 12:50 PM
> To: dev <de...@cloudstack.apache.org>
> Cc: users <us...@cloudstack.apache.org>
> Subject: [VOTE] next version 20 instead of 4.20
>
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
> --
> Daan
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Daan Hoogland <da...@gmail.com>.
Paul,
On Mon, Feb 19, 2024 at 6:21 PM Paul Angus <pa...@angus.uk.com.invalid> wrote:
>
> Hi Daan,
>
> Can you clarify what we are actually voting on please.
>
> In thread that is linked I've seen:
>
> "[the vote] will be to adjust to the semantic versioning system."
> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
We are using a crooked semantic versioning system and that is entirely
due to maintaining the 4 in our versioning scheme. We have been
changing and adding major features on updating the second number (20
to be). We have been using the third number for bug fixes and minor
enhancements. And we have been using the fourth number for emergency
security fixes.
So we are not maintaining semantic versioning but going to semantic
versioning by repairing our system of versioning. You could say this
is a minor bugfix.
>
> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
Yes, exactly. Except for dropping the 4, nothing will change.
>
> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>
>
> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>
>
>
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>
> -----Original Message-----
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, February 19, 2024 12:50 PM
> To: dev <de...@cloudstack.apache.org>
> Cc: users <us...@cloudstack.apache.org>
> Subject: [VOTE] next version 20 instead of 4.20
>
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
> --
> Daan
--
Daan
RE: [VOTE] next version 20 instead of 4.20
Posted by Paul Angus <pa...@angus.uk.com.INVALID>.
That logic doesn't hold with what's proposed
Taking your interpretation, after moving to 20.x.y we would then have to stay on 20.x.y until "incompatible API changes" happen. New features and updates would go into 20 . x+1 . y which only achieves removing the security fix dot releases nomenclature.
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Wednesday, March 6, 2024 8:57 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
I think we will (and have) changed APIs and dropped plugin support in major versions with at least a deprecation period. this is exactly the reason I now (finally) proposed we should drop the 4 and proceed with regarding the second number as the primary version. Semantic versioning is well defined as a three number scheme that we follow otherwise.
this is also how https://semver.org/ defines it. Our only difference with that is that we do not allow backwards compatible feature added in major versions, which we could decide to do or don't independent of whether we drop the 4 or not.
I agree that we could codify our protocol first.
On Wed, Mar 6, 2024 at 5:54 AM Rohit Yadav <ro...@shapeblue.com> wrote:
>
> Daniel, Daan, others,
>
> Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the intention of dropping the 4. as we may never see a 5.x that involves major changes involving API incompatibility?
>
> Regards.
>
>
>
> ________________________________
> From: Guto Veronezi <gu...@apache.org>
> Sent: Wednesday, March 6, 2024 4:00:30 AM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> > By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs.
> That is not what was discussed in the thread [1]. If we agree that we
> will not break APIs, I am -1 on dropping the "4". We need to create a
> protocol along with the proposal, otherwise, we will be subjective
> about the topic and will be agreeing on something for different reasons.
>
> [1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
>
> On 3/5/24 15:10, Paul Angus wrote:
> > Hi Rohit, thank you
> >
> > So to recap;
> >
> > Semantic versioning goes (in our use):
> > <EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> .
> > <BUG_FIXES> . <SECURITY_FIXES>
> >
> > And as I understand it you're looking to go
> >
> > <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES> Starting
> > from 20
> >
> > I'd ask the question - are there any big/disruptive changes people
> > would want to bundle together to keep the semantic versioning and
> > move to 5.x.y.z
> >
> > I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
> >
> > I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
> >
> > So, to be pedantic, and have a clearly defined vote, I'd change the
> > vote to something like "Drop semantic versioning and continue from
> > 20". And include your explanation about moving to
> > <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
> >
> > I would be ok to +1 that ^^^
> >
> > -paul
> >
> > -----Original Message-----
> > From: Rohit Yadav <ro...@shapeblue.com>
> > Sent: Tuesday, March 5, 2024 4:02 PM
> > To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> > Subject: Re: [VOTE] next version 20 instead of 4.20
> >
> > As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
> >
> > The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
> >
> > Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
> >
> >
> > Regards.
> >
> >
> >
> >
> > ________________________________
> > From: Paul Angus <pa...@apache.org>
> > Sent: Tuesday, February 20, 2024 15:55
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
> > Subject: RE: [VOTE] next version 20 instead of 4.20
> >
> > Hi Daan,
> >
> >
> > From our wiki page:
> >
> > -- Quote
> > For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
> >
> > In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
> > -- End quote.
> >
> >
> > Specifically:
> > The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
> >
> >
> > From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
> >
> > Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
> >
> > - Paul
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Tuesday, February 20, 2024 10:05 AM
> > To: users@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: [VOTE] next version 20 instead of 4.20
> >
> > Vivek, we could, but the main idea is that we repair our versioning
> > system and make clear how we are actually dealing with our current
> > system, which is major - new , possibly breaking features minor -
> > improvements and enhancements tiny - urgent (security) fixes
> >
> > and in addition we would go to 20 to indicate that is the follower
> > of
> > 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5
> > for
> > instance) but this would not have anything to do with our current versioning system.
> >
> > On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
> >> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
> >>
> >>
> >>> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >>>
> >>> Hi Daan,
> >>>
> >>> Can you clarify what we are actually voting on please.
> >>>
> >>> In thread that is linked I've seen:
> >>>
> >>> "[the vote] will be to adjust to the semantic versioning system."
> >>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >>>
> >>> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> >>> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >>>
> >>> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >>>
> >>>
> >>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >>>
> >>>
> >>>
> >>>
> >>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >>>
> >>> -----Original Message-----
> >>> From: Daan Hoogland <da...@gmail.com>
> >>> Sent: Monday, February 19, 2024 12:50 PM
> >>> To: dev <de...@cloudstack.apache.org>
> >>> Cc: users <us...@cloudstack.apache.org>
> >>> Subject: [VOTE] next version 20 instead of 4.20
> >>>
> >>> LS,
> >>>
> >>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >>>
> >>> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >>>
> >>> +1 agree (next major version as 20
> >>> 0 (no opinion)
> >>> -1 disagree (keep 4.20 as the next version, give a reason)
> >>>
> >>> As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >>>
> >>> [1]
> >>> https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >>>
> >>> --
> >>> Daan
> >>
> >> --
> >> This message is intended only for the use of the individual or
> >> entity to which it is addressed and may contain confidential and/or
> >> privileged information. If you are not the intended recipient,
> >> please delete the original message and any copy of it from your
> >> computer system. You are hereby notified that any dissemination,
> >> distribution or copying of this communication is strictly
> >> prohibited unless proper authorization has been obtained for such
> >> action. If you have received this communication in error, please notify the sender immediately.
> >> Although IndiQus attempts to sweep e-mail and attachments for
> >> viruses, it does not guarantee that both are virus-free and accepts
> >> no liability for any damage sustained as a result of viruses.
> >
> >
> > --
> > Daan
> >
> >
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Daan Hoogland <da...@gmail.com>.
I think we will (and have) changed APIs and dropped plugin support in
major versions with at least a deprecation period. this is exactly the
reason I now (finally) proposed we should drop the 4 and proceed with
regarding the second number as the primary version. Semantic
versioning is well defined as a three number scheme that we follow
otherwise.
this is also how https://semver.org/ defines it. Our only difference
with that is that we do not allow backwards compatible feature added
in major versions, which we could decide to do or don't independent of
whether we drop the 4 or not.
I agree that we could codify our protocol first.
On Wed, Mar 6, 2024 at 5:54 AM Rohit Yadav <ro...@shapeblue.com> wrote:
>
> Daniel, Daan, others,
>
> Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the intention of dropping the 4. as we may never see a 5.x that involves major changes involving API incompatibility?
>
> Regards.
>
>
>
> ________________________________
> From: Guto Veronezi <gu...@apache.org>
> Sent: Wednesday, March 6, 2024 4:00:30 AM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> > By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs.
> That is not what was discussed in the thread [1]. If we agree that we
> will not break APIs, I am -1 on dropping the "4". We need to create a
> protocol along with the proposal, otherwise, we will be subjective about
> the topic and will be agreeing on something for different reasons.
>
> [1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
>
> On 3/5/24 15:10, Paul Angus wrote:
> > Hi Rohit, thank you
> >
> > So to recap;
> >
> > Semantic versioning goes (in our use):
> > <EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
> >
> > And as I understand it you're looking to go
> >
> > <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
> > Starting from 20
> >
> > I'd ask the question - are there any big/disruptive changes people would want to bundle together to keep the semantic versioning and move to 5.x.y.z
> >
> > I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
> >
> > I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
> >
> > So, to be pedantic, and have a clearly defined vote, I'd change the vote to something like "Drop semantic versioning and continue from 20". And include your explanation about moving to
> > <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
> >
> > I would be ok to +1 that ^^^
> >
> > -paul
> >
> > -----Original Message-----
> > From: Rohit Yadav <ro...@shapeblue.com>
> > Sent: Tuesday, March 5, 2024 4:02 PM
> > To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> > Subject: Re: [VOTE] next version 20 instead of 4.20
> >
> > As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
> >
> > The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
> >
> > Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
> >
> >
> > Regards.
> >
> >
> >
> >
> > ________________________________
> > From: Paul Angus <pa...@apache.org>
> > Sent: Tuesday, February 20, 2024 15:55
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
> > Subject: RE: [VOTE] next version 20 instead of 4.20
> >
> > Hi Daan,
> >
> >
> > From our wiki page:
> >
> > -- Quote
> > For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
> >
> > In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
> > -- End quote.
> >
> >
> > Specifically:
> > The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
> >
> >
> > From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
> >
> > Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
> >
> > - Paul
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Tuesday, February 20, 2024 10:05 AM
> > To: users@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: [VOTE] next version 20 instead of 4.20
> >
> > Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
> >
> > and in addition we would go to 20 to indicate that is the follower of
> > 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
> > instance) but this would not have anything to do with our current versioning system.
> >
> > On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
> >> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
> >>
> >>
> >>> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >>>
> >>> Hi Daan,
> >>>
> >>> Can you clarify what we are actually voting on please.
> >>>
> >>> In thread that is linked I've seen:
> >>>
> >>> "[the vote] will be to adjust to the semantic versioning system."
> >>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >>>
> >>> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> >>> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >>>
> >>> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >>>
> >>>
> >>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >>>
> >>>
> >>>
> >>>
> >>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >>>
> >>> -----Original Message-----
> >>> From: Daan Hoogland <da...@gmail.com>
> >>> Sent: Monday, February 19, 2024 12:50 PM
> >>> To: dev <de...@cloudstack.apache.org>
> >>> Cc: users <us...@cloudstack.apache.org>
> >>> Subject: [VOTE] next version 20 instead of 4.20
> >>>
> >>> LS,
> >>>
> >>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >>>
> >>> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >>>
> >>> +1 agree (next major version as 20
> >>> 0 (no opinion)
> >>> -1 disagree (keep 4.20 as the next version, give a reason)
> >>>
> >>> As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >>>
> >>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >>>
> >>> --
> >>> Daan
> >>
> >> --
> >> This message is intended only for the use of the individual or entity
> >> to which it is addressed and may contain confidential and/or
> >> privileged information. If you are not the intended recipient, please
> >> delete the original message and any copy of it from your computer
> >> system. You are hereby notified that any dissemination, distribution
> >> or copying of this communication is strictly prohibited unless proper
> >> authorization has been obtained for such action. If you have received
> >> this communication in error, please notify the sender immediately.
> >> Although IndiQus attempts to sweep e-mail and attachments for viruses,
> >> it does not guarantee that both are virus-free and accepts no
> >> liability for any damage sustained as a result of viruses.
> >
> >
> > --
> > Daan
> >
> >
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Rohit Yadav <ro...@shapeblue.com>.
Joao,
Could you start a separate [DISCUSS] thread, this is because your proposal is important in the context of future of ACS releases, but different from what this voting thread is about.
There are no bylaw(s) on how many releases should be done in a year or have them done in a certain way; we have adopted a community-agreed guideline to have 1-2 major releases a year to ship new features to users (some find this faster; some find this slower still). I think there is scope of improving those guidelines. However, any committer or PMC (or even a contributor with committer/PMC support) should be able to volunteer and help lead a release as its release manager.
The current development and release model has over the years seen deprecation and removal of features and components, such as API components (awsapi), (legacy) UI and old/unmaintained plugins. This is usually done over a course of time and releases with some support building and documentation/advisory, to allow feedback from the community. For deprecating justified areas and reasonable components of CloudStack, we can still do it without a new release model.
I believe the imporant thing is to iterate a proposal that would be generally accepted and benefial for the larger community, and generaly not breaking CloudStack's userspace to the effect that it breaks users' automation, integration, systems and tooling that are built on top of CloudStack.
Regards.
________________________________
From: João Jandre Paraquetti <jo...@scclouds.com.br>
Sent: Thursday, March 14, 2024 23:49
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [VOTE] next version 20 instead of 4.20
Hi all,
I know that this discussion has cooled off, but I think it's still
extremely relevant for the future of ACS. That being said, I have
another proposal for the versioning scheme. Instead of dropping the "X"
on our X.Y.Z.N, we can set a fixed schedule (that can be further
discussed) for the version changes:
- Every two years, we release a major version (X), which can contain
changes that break backward compatibility, such as (but not limited to):
removing unused/useless APIs, renaming APIs, and changing the default
behavior of features. These changes must be discussed with the devs and
be properly communicated to the community (via API deprecation, for
example) at least one minor version before the major release;
- Every semester, we release a minor version (Y) of the current major
(X) version, these can contain new features/APIs, as long as the
backward compatibility is maintained; also, feature/API deprecation
should happen on these versions;
- Every 2/3 months, we release patch versions (Z), that fix any bugs
that were released with the major and minor versions, these versions
should not contain any new features;
- In extreme cases (such as with security issues) we work on and release
security versions (N);
The proposed schedule is only a sketch that can be worked on. However I
believe that the project can benefit from:
1. A fixed release schedule;
2. A mechanism to introduce disruptive changes, so that the project can
evolve and not be chained to the same features/API/limitation/technical
debts forever.
Furthermore, having a schedule allows us to have a project roadmap, that
outlines the future deprecations, changes and big features.
Best Regards,
João Jandre.
On 3/6/24 07:11, Giles Sirett wrote:
> IMO - they are two different subjects.
> Everybody hopes that we'd never break API compatibility, but there may be a situation at some point in the future where it may be required and we fundamentally cant take a decision now that limits what the community may want to do in 10 years time. Irrespective of what numbering scheme is being used, that would still be a massive decision to make *at the time* and I'd expect a vibrant debate on doing so
>
>
> Yes, semantic is a well know agreed standard: giving consistency across lots of different software - but there is absolutely nothing to say that CloudStack HAS to stick to that convention (arguably, by removing the "4." , we're coming away from that standard anyway) Lots of software doesn’t use semantic release versioning at all.
>
> As long as we have a consistent versioning scheme and are clear about it - it doesn’t matter what scheme we use IMO
>
> As Paul says the "X" in X.Y.Z is usually used as a simple way to warn of API disruptive changes - but that warning can be given in other ways (in documentation , a compatibility matrix, etc) *If* it ever happened, we would be using the first number for both <EXTREAMLY_DISRUPTIVE_CHANGES> and <NEW/IMPROVED_FEATURES>
>
>
> Kind Regards
> Giles
>
>
>
>
> -----Original Message-----
> From: Rohit Yadav <ro...@shapeblue.com>
> Sent: Wednesday, March 6, 2024 4:54 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> Daniel, Daan, others,
>
> Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the intention of dropping the 4. as we may never see a 5.x that involves major changes involving API incompatibility?
>
> Regards.
>
>
>
> ________________________________
> From: Guto Veronezi <gu...@apache.org>
> Sent: Wednesday, March 6, 2024 4:00:30 AM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
>> By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs.
> That is not what was discussed in the thread [1]. If we agree that we will not break APIs, I am -1 on dropping the "4". We need to create a protocol along with the proposal, otherwise, we will be subjective about the topic and will be agreeing on something for different reasons.
>
> [1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
>
> On 3/5/24 15:10, Paul Angus wrote:
>> Hi Rohit, thank you
>>
>> So to recap;
>>
>> Semantic versioning goes (in our use):
>> <EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES>
>> . <SECURITY_FIXES>
>>
>> And as I understand it you're looking to go
>>
>> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES> Starting from
>> 20
>>
>> I'd ask the question - are there any big/disruptive changes people
>> would want to bundle together to keep the semantic versioning and move
>> to 5.x.y.z
>>
>> I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
>>
>> I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
>>
>> So, to be pedantic, and have a clearly defined vote, I'd change the
>> vote to something like "Drop semantic versioning and continue from
>> 20". And include your explanation about moving to
>> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
>>
>> I would be ok to +1 that ^^^
>>
>> -paul
>>
>> -----Original Message-----
>> From: Rohit Yadav <ro...@shapeblue.com>
>> Sent: Tuesday, March 5, 2024 4:02 PM
>> To: dev@cloudstack.apache.org; users@cloudstack.apache.org
>> Subject: Re: [VOTE] next version 20 instead of 4.20
>>
>> As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
>>
>> The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
>>
>> Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
>>
>>
>> Regards.
>>
>>
>>
>>
>> ________________________________
>> From: Paul Angus <pa...@apache.org>
>> Sent: Tuesday, February 20, 2024 15:55
>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>> Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
>> Subject: RE: [VOTE] next version 20 instead of 4.20
>>
>> Hi Daan,
>>
>>
>> From our wiki page:
>>
>> -- Quote
>> For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>>
>> In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
>> -- End quote.
>>
>>
>> Specifically:
>> The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>>
>>
>> From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
>>
>> Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
>>
>> - Paul
>>
>> -----Original Message-----
>> From: Daan Hoogland <da...@gmail.com>
>> Sent: Tuesday, February 20, 2024 10:05 AM
>> To: users@cloudstack.apache.org
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] next version 20 instead of 4.20
>>
>> Vivek, we could, but the main idea is that we repair our versioning
>> system and make clear how we are actually dealing with our current
>> system, which is major - new , possibly breaking features minor -
>> improvements and enhancements tiny - urgent (security) fixes
>>
>> and in addition we would go to 20 to indicate that is the follower of
>> 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
>> instance) but this would not have anything to do with our current versioning system.
>>
>> On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>>> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>>>
>>>
>>>
> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
>>>>
>>>> Hi Daan,
>>>>
>>>> Can you clarify what we are actually voting on please.
>>>>
>>>> In thread that is linked I've seen:
>>>>
>>>> "[the vote] will be to adjust to the semantic versioning system."
>>>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
>>>>
>>>> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
>>>> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
>>>>
>>>> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>>>>
>>>>
>>>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>>>>
>>>>
>>>>
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>>>>
>>>> -----Original Message-----
>>>> From: Daan Hoogland <da...@gmail.com>
>>>> Sent: Monday, February 19, 2024 12:50 PM
>>>> To: dev <de...@cloudstack.apache.org>
>>>> Cc: users <us...@cloudstack.apache.org>
>>>> Subject: [VOTE] next version 20 instead of 4.20
>>>>
>>>> LS,
>>>>
>>>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>>>>
>>>> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>>>>
>>>> +1 agree (next major version as 20
>>>> 0 (no opinion)
>>>> -1 disagree (keep 4.20 as the next version, give a reason)
>>>>
>>>> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>>>>
>>>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>>>>
>>>> --
>>>> Daan
>>> --
>>> This message is intended only for the use of the individual or entity
>>> to which it is addressed and may contain confidential and/or
>>> privileged information. If you are not the intended recipient, please
>>> delete the original message and any copy of it from your computer
>>> system. You are hereby notified that any dissemination, distribution
>>> or copying of this communication is strictly prohibited unless proper
>>> authorization has been obtained for such action. If you have received
>>> this communication in error, please notify the sender immediately.
>>> Although IndiQus attempts to sweep e-mail and attachments for
>>> viruses, it does not guarantee that both are virus-free and accepts
>>> no liability for any damage sustained as a result of viruses.
>>
>> --
>> Daan
>>
>>
Re: [VOTE] next version 20 instead of 4.20
Posted by João Jandre Paraquetti <jo...@scclouds.com.br>.
Hi all,
I know that this discussion has cooled off, but I think it's still
extremely relevant for the future of ACS. That being said, I have
another proposal for the versioning scheme. Instead of dropping the "X"
on our X.Y.Z.N, we can set a fixed schedule (that can be further
discussed) for the version changes:
- Every two years, we release a major version (X), which can contain
changes that break backward compatibility, such as (but not limited to):
removing unused/useless APIs, renaming APIs, and changing the default
behavior of features. These changes must be discussed with the devs and
be properly communicated to the community (via API deprecation, for
example) at least one minor version before the major release;
- Every semester, we release a minor version (Y) of the current major
(X) version, these can contain new features/APIs, as long as the
backward compatibility is maintained; also, feature/API deprecation
should happen on these versions;
- Every 2/3 months, we release patch versions (Z), that fix any bugs
that were released with the major and minor versions, these versions
should not contain any new features;
- In extreme cases (such as with security issues) we work on and release
security versions (N);
The proposed schedule is only a sketch that can be worked on. However I
believe that the project can benefit from:
1. A fixed release schedule;
2. A mechanism to introduce disruptive changes, so that the project can
evolve and not be chained to the same features/API/limitation/technical
debts forever.
Furthermore, having a schedule allows us to have a project roadmap, that
outlines the future deprecations, changes and big features.
Best Regards,
João Jandre.
On 3/6/24 07:11, Giles Sirett wrote:
> IMO - they are two different subjects.
> Everybody hopes that we'd never break API compatibility, but there may be a situation at some point in the future where it may be required and we fundamentally cant take a decision now that limits what the community may want to do in 10 years time. Irrespective of what numbering scheme is being used, that would still be a massive decision to make *at the time* and I'd expect a vibrant debate on doing so
>
>
> Yes, semantic is a well know agreed standard: giving consistency across lots of different software - but there is absolutely nothing to say that CloudStack HAS to stick to that convention (arguably, by removing the "4." , we're coming away from that standard anyway) Lots of software doesn’t use semantic release versioning at all.
>
> As long as we have a consistent versioning scheme and are clear about it - it doesn’t matter what scheme we use IMO
>
> As Paul says the "X" in X.Y.Z is usually used as a simple way to warn of API disruptive changes - but that warning can be given in other ways (in documentation , a compatibility matrix, etc) *If* it ever happened, we would be using the first number for both <EXTREAMLY_DISRUPTIVE_CHANGES> and <NEW/IMPROVED_FEATURES>
>
>
> Kind Regards
> Giles
>
>
>
>
> -----Original Message-----
> From: Rohit Yadav <ro...@shapeblue.com>
> Sent: Wednesday, March 6, 2024 4:54 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> Daniel, Daan, others,
>
> Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the intention of dropping the 4. as we may never see a 5.x that involves major changes involving API incompatibility?
>
> Regards.
>
>
>
> ________________________________
> From: Guto Veronezi <gu...@apache.org>
> Sent: Wednesday, March 6, 2024 4:00:30 AM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
>> By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs.
> That is not what was discussed in the thread [1]. If we agree that we will not break APIs, I am -1 on dropping the "4". We need to create a protocol along with the proposal, otherwise, we will be subjective about the topic and will be agreeing on something for different reasons.
>
> [1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
>
> On 3/5/24 15:10, Paul Angus wrote:
>> Hi Rohit, thank you
>>
>> So to recap;
>>
>> Semantic versioning goes (in our use):
>> <EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES>
>> . <SECURITY_FIXES>
>>
>> And as I understand it you're looking to go
>>
>> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES> Starting from
>> 20
>>
>> I'd ask the question - are there any big/disruptive changes people
>> would want to bundle together to keep the semantic versioning and move
>> to 5.x.y.z
>>
>> I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
>>
>> I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
>>
>> So, to be pedantic, and have a clearly defined vote, I'd change the
>> vote to something like "Drop semantic versioning and continue from
>> 20". And include your explanation about moving to
>> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
>>
>> I would be ok to +1 that ^^^
>>
>> -paul
>>
>> -----Original Message-----
>> From: Rohit Yadav <ro...@shapeblue.com>
>> Sent: Tuesday, March 5, 2024 4:02 PM
>> To: dev@cloudstack.apache.org; users@cloudstack.apache.org
>> Subject: Re: [VOTE] next version 20 instead of 4.20
>>
>> As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
>>
>> The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
>>
>> Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
>>
>>
>> Regards.
>>
>>
>>
>>
>> ________________________________
>> From: Paul Angus <pa...@apache.org>
>> Sent: Tuesday, February 20, 2024 15:55
>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>> Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
>> Subject: RE: [VOTE] next version 20 instead of 4.20
>>
>> Hi Daan,
>>
>>
>> From our wiki page:
>>
>> -- Quote
>> For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>>
>> In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
>> -- End quote.
>>
>>
>> Specifically:
>> The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>>
>>
>> From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
>>
>> Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
>>
>> - Paul
>>
>> -----Original Message-----
>> From: Daan Hoogland <da...@gmail.com>
>> Sent: Tuesday, February 20, 2024 10:05 AM
>> To: users@cloudstack.apache.org
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] next version 20 instead of 4.20
>>
>> Vivek, we could, but the main idea is that we repair our versioning
>> system and make clear how we are actually dealing with our current
>> system, which is major - new , possibly breaking features minor -
>> improvements and enhancements tiny - urgent (security) fixes
>>
>> and in addition we would go to 20 to indicate that is the follower of
>> 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
>> instance) but this would not have anything to do with our current versioning system.
>>
>> On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>>> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>>>
>>>
>>>> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
>>>>
>>>> Hi Daan,
>>>>
>>>> Can you clarify what we are actually voting on please.
>>>>
>>>> In thread that is linked I've seen:
>>>>
>>>> "[the vote] will be to adjust to the semantic versioning system."
>>>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
>>>>
>>>> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
>>>> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
>>>>
>>>> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>>>>
>>>>
>>>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>>>>
>>>>
>>>>
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>>>>
>>>> -----Original Message-----
>>>> From: Daan Hoogland <da...@gmail.com>
>>>> Sent: Monday, February 19, 2024 12:50 PM
>>>> To: dev <de...@cloudstack.apache.org>
>>>> Cc: users <us...@cloudstack.apache.org>
>>>> Subject: [VOTE] next version 20 instead of 4.20
>>>>
>>>> LS,
>>>>
>>>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>>>>
>>>> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>>>>
>>>> +1 agree (next major version as 20
>>>> 0 (no opinion)
>>>> -1 disagree (keep 4.20 as the next version, give a reason)
>>>>
>>>> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>>>>
>>>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>>>>
>>>> --
>>>> Daan
>>> --
>>> This message is intended only for the use of the individual or entity
>>> to which it is addressed and may contain confidential and/or
>>> privileged information. If you are not the intended recipient, please
>>> delete the original message and any copy of it from your computer
>>> system. You are hereby notified that any dissemination, distribution
>>> or copying of this communication is strictly prohibited unless proper
>>> authorization has been obtained for such action. If you have received
>>> this communication in error, please notify the sender immediately.
>>> Although IndiQus attempts to sweep e-mail and attachments for
>>> viruses, it does not guarantee that both are virus-free and accepts
>>> no liability for any damage sustained as a result of viruses.
>>
>> --
>> Daan
>>
>>
RE: [VOTE] next version 20 instead of 4.20
Posted by Giles Sirett <gi...@shapeblue.com>.
IMO - they are two different subjects.
Everybody hopes that we'd never break API compatibility, but there may be a situation at some point in the future where it may be required and we fundamentally cant take a decision now that limits what the community may want to do in 10 years time. Irrespective of what numbering scheme is being used, that would still be a massive decision to make *at the time* and I'd expect a vibrant debate on doing so
Yes, semantic is a well know agreed standard: giving consistency across lots of different software - but there is absolutely nothing to say that CloudStack HAS to stick to that convention (arguably, by removing the "4." , we're coming away from that standard anyway) Lots of software doesn’t use semantic release versioning at all.
As long as we have a consistent versioning scheme and are clear about it - it doesn’t matter what scheme we use IMO
As Paul says the "X" in X.Y.Z is usually used as a simple way to warn of API disruptive changes - but that warning can be given in other ways (in documentation , a compatibility matrix, etc) *If* it ever happened, we would be using the first number for both <EXTREAMLY_DISRUPTIVE_CHANGES> and <NEW/IMPROVED_FEATURES>
Kind Regards
Giles
-----Original Message-----
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Wednesday, March 6, 2024 4:54 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
Daniel, Daan, others,
Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the intention of dropping the 4. as we may never see a 5.x that involves major changes involving API incompatibility?
Regards.
________________________________
From: Guto Veronezi <gu...@apache.org>
Sent: Wednesday, March 6, 2024 4:00:30 AM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [VOTE] next version 20 instead of 4.20
> By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs.
That is not what was discussed in the thread [1]. If we agree that we will not break APIs, I am -1 on dropping the "4". We need to create a protocol along with the proposal, otherwise, we will be subjective about the topic and will be agreeing on something for different reasons.
[1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
On 3/5/24 15:10, Paul Angus wrote:
> Hi Rohit, thank you
>
> So to recap;
>
> Semantic versioning goes (in our use):
> <EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES>
> . <SECURITY_FIXES>
>
> And as I understand it you're looking to go
>
> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES> Starting from
> 20
>
> I'd ask the question - are there any big/disruptive changes people
> would want to bundle together to keep the semantic versioning and move
> to 5.x.y.z
>
> I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
>
> I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
>
> So, to be pedantic, and have a clearly defined vote, I'd change the
> vote to something like "Drop semantic versioning and continue from
> 20". And include your explanation about moving to
> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
>
> I would be ok to +1 that ^^^
>
> -paul
>
> -----Original Message-----
> From: Rohit Yadav <ro...@shapeblue.com>
> Sent: Tuesday, March 5, 2024 4:02 PM
> To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
>
> The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
>
> Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
>
>
> Regards.
>
>
>
>
> ________________________________
> From: Paul Angus <pa...@apache.org>
> Sent: Tuesday, February 20, 2024 15:55
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
> Subject: RE: [VOTE] next version 20 instead of 4.20
>
> Hi Daan,
>
>
> From our wiki page:
>
> -- Quote
> For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>
> In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
> -- End quote.
>
>
> Specifically:
> The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>
>
> From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
>
> Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
>
> - Paul
>
> -----Original Message-----
> From: Daan Hoogland <da...@gmail.com>
> Sent: Tuesday, February 20, 2024 10:05 AM
> To: users@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> Vivek, we could, but the main idea is that we repair our versioning
> system and make clear how we are actually dealing with our current
> system, which is major - new , possibly breaking features minor -
> improvements and enhancements tiny - urgent (security) fixes
>
> and in addition we would go to 20 to indicate that is the follower of
> 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
> instance) but this would not have anything to do with our current versioning system.
>
> On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>>
>>
>>> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
>>>
>>> Hi Daan,
>>>
>>> Can you clarify what we are actually voting on please.
>>>
>>> In thread that is linked I've seen:
>>>
>>> "[the vote] will be to adjust to the semantic versioning system."
>>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
>>>
>>> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
>>> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
>>>
>>> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>>>
>>>
>>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>>>
>>>
>>>
>>>
>>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>>>
>>> -----Original Message-----
>>> From: Daan Hoogland <da...@gmail.com>
>>> Sent: Monday, February 19, 2024 12:50 PM
>>> To: dev <de...@cloudstack.apache.org>
>>> Cc: users <us...@cloudstack.apache.org>
>>> Subject: [VOTE] next version 20 instead of 4.20
>>>
>>> LS,
>>>
>>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>>>
>>> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>>>
>>> +1 agree (next major version as 20
>>> 0 (no opinion)
>>> -1 disagree (keep 4.20 as the next version, give a reason)
>>>
>>> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>>>
>>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>>>
>>> --
>>> Daan
>>
>> --
>> This message is intended only for the use of the individual or entity
>> to which it is addressed and may contain confidential and/or
>> privileged information. If you are not the intended recipient, please
>> delete the original message and any copy of it from your computer
>> system. You are hereby notified that any dissemination, distribution
>> or copying of this communication is strictly prohibited unless proper
>> authorization has been obtained for such action. If you have received
>> this communication in error, please notify the sender immediately.
>> Although IndiQus attempts to sweep e-mail and attachments for
>> viruses, it does not guarantee that both are virus-free and accepts
>> no liability for any damage sustained as a result of viruses.
>
>
> --
> Daan
>
>
Re: [VOTE] next version 20 instead of 4.20
Posted by Rohit Yadav <ro...@shapeblue.com>.
Daniel, Daan, others,
Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the intention of dropping the 4. as we may never see a 5.x that involves major changes involving API incompatibility?
Regards.
________________________________
From: Guto Veronezi <gu...@apache.org>
Sent: Wednesday, March 6, 2024 4:00:30 AM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [VOTE] next version 20 instead of 4.20
> By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs.
That is not what was discussed in the thread [1]. If we agree that we
will not break APIs, I am -1 on dropping the "4". We need to create a
protocol along with the proposal, otherwise, we will be subjective about
the topic and will be agreeing on something for different reasons.
[1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
On 3/5/24 15:10, Paul Angus wrote:
> Hi Rohit, thank you
>
> So to recap;
>
> Semantic versioning goes (in our use):
> <EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
>
> And as I understand it you're looking to go
>
> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
> Starting from 20
>
> I'd ask the question - are there any big/disruptive changes people would want to bundle together to keep the semantic versioning and move to 5.x.y.z
>
> I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
>
> I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
>
> So, to be pedantic, and have a clearly defined vote, I'd change the vote to something like "Drop semantic versioning and continue from 20". And include your explanation about moving to
> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
>
> I would be ok to +1 that ^^^
>
> -paul
>
> -----Original Message-----
> From: Rohit Yadav <ro...@shapeblue.com>
> Sent: Tuesday, March 5, 2024 4:02 PM
> To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
>
> The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
>
> Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
>
>
> Regards.
>
>
>
>
> ________________________________
> From: Paul Angus <pa...@apache.org>
> Sent: Tuesday, February 20, 2024 15:55
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
> Subject: RE: [VOTE] next version 20 instead of 4.20
>
> Hi Daan,
>
>
> From our wiki page:
>
> -- Quote
> For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>
> In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
> -- End quote.
>
>
> Specifically:
> The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>
>
> From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
>
> Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
>
> - Paul
>
> -----Original Message-----
> From: Daan Hoogland <da...@gmail.com>
> Sent: Tuesday, February 20, 2024 10:05 AM
> To: users@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
>
> and in addition we would go to 20 to indicate that is the follower of
> 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
> instance) but this would not have anything to do with our current versioning system.
>
> On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>>
>>
>>> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
>>>
>>> Hi Daan,
>>>
>>> Can you clarify what we are actually voting on please.
>>>
>>> In thread that is linked I've seen:
>>>
>>> "[the vote] will be to adjust to the semantic versioning system."
>>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
>>>
>>> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
>>> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
>>>
>>> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>>>
>>>
>>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>>>
>>>
>>>
>>>
>>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>>>
>>> -----Original Message-----
>>> From: Daan Hoogland <da...@gmail.com>
>>> Sent: Monday, February 19, 2024 12:50 PM
>>> To: dev <de...@cloudstack.apache.org>
>>> Cc: users <us...@cloudstack.apache.org>
>>> Subject: [VOTE] next version 20 instead of 4.20
>>>
>>> LS,
>>>
>>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>>>
>>> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>>>
>>> +1 agree (next major version as 20
>>> 0 (no opinion)
>>> -1 disagree (keep 4.20 as the next version, give a reason)
>>>
>>> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>>>
>>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>>>
>>> --
>>> Daan
>>
>> --
>> This message is intended only for the use of the individual or entity
>> to which it is addressed and may contain confidential and/or
>> privileged information. If you are not the intended recipient, please
>> delete the original message and any copy of it from your computer
>> system. You are hereby notified that any dissemination, distribution
>> or copying of this communication is strictly prohibited unless proper
>> authorization has been obtained for such action. If you have received
>> this communication in error, please notify the sender immediately.
>> Although IndiQus attempts to sweep e-mail and attachments for viruses,
>> it does not guarantee that both are virus-free and accepts no
>> liability for any damage sustained as a result of viruses.
>
>
> --
> Daan
>
>
Re: [VOTE] next version 20 instead of 4.20
Posted by Guto Veronezi <gu...@apache.org>.
> By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs.
That is not what was discussed in the thread [1]. If we agree that we
will not break APIs, I am -1 on dropping the "4". We need to create a
protocol along with the proposal, otherwise, we will be subjective about
the topic and will be agreeing on something for different reasons.
[1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
On 3/5/24 15:10, Paul Angus wrote:
> Hi Rohit, thank you
>
> So to recap;
>
> Semantic versioning goes (in our use):
> <EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
>
> And as I understand it you're looking to go
>
> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
> Starting from 20
>
> I'd ask the question - are there any big/disruptive changes people would want to bundle together to keep the semantic versioning and move to 5.x.y.z
>
> I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
>
> I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
>
> So, to be pedantic, and have a clearly defined vote, I'd change the vote to something like "Drop semantic versioning and continue from 20". And include your explanation about moving to
> <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
>
> I would be ok to +1 that ^^^
>
> -paul
>
> -----Original Message-----
> From: Rohit Yadav <ro...@shapeblue.com>
> Sent: Tuesday, March 5, 2024 4:02 PM
> To: dev@cloudstack.apache.org; users@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
>
> The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
>
> Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
>
>
> Regards.
>
>
>
>
> ________________________________
> From: Paul Angus <pa...@apache.org>
> Sent: Tuesday, February 20, 2024 15:55
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
> Subject: RE: [VOTE] next version 20 instead of 4.20
>
> Hi Daan,
>
>
> From our wiki page:
>
> -- Quote
> For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>
> In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
> -- End quote.
>
>
> Specifically:
> The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
>
>
> From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
>
> Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
>
> - Paul
>
> -----Original Message-----
> From: Daan Hoogland <da...@gmail.com>
> Sent: Tuesday, February 20, 2024 10:05 AM
> To: users@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
>
> and in addition we would go to 20 to indicate that is the follower of
> 4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
> instance) but this would not have anything to do with our current versioning system.
>
> On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>>
>>
>>> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
>>>
>>> Hi Daan,
>>>
>>> Can you clarify what we are actually voting on please.
>>>
>>> In thread that is linked I've seen:
>>>
>>> "[the vote] will be to adjust to the semantic versioning system."
>>> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
>>>
>>> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
>>> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
>>>
>>> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>>>
>>>
>>> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>>>
>>>
>>>
>>>
>>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>>>
>>> -----Original Message-----
>>> From: Daan Hoogland <da...@gmail.com>
>>> Sent: Monday, February 19, 2024 12:50 PM
>>> To: dev <de...@cloudstack.apache.org>
>>> Cc: users <us...@cloudstack.apache.org>
>>> Subject: [VOTE] next version 20 instead of 4.20
>>>
>>> LS,
>>>
>>> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>>>
>>> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>>>
>>> +1 agree (next major version as 20
>>> 0 (no opinion)
>>> -1 disagree (keep 4.20 as the next version, give a reason)
>>>
>>> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>>>
>>> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>>>
>>> --
>>> Daan
>>
>> --
>> This message is intended only for the use of the individual or entity
>> to which it is addressed and may contain confidential and/or
>> privileged information. If you are not the intended recipient, please
>> delete the original message and any copy of it from your computer
>> system. You are hereby notified that any dissemination, distribution
>> or copying of this communication is strictly prohibited unless proper
>> authorization has been obtained for such action. If you have received
>> this communication in error, please notify the sender immediately.
>> Although IndiQus attempts to sweep e-mail and attachments for viruses,
>> it does not guarantee that both are virus-free and accepts no
>> liability for any damage sustained as a result of viruses.
>
>
> --
> Daan
>
>
RE: [VOTE] next version 20 instead of 4.20
Posted by Paul Angus <pa...@apache.org>.
Hi Rohit, thank you
So to recap;
Semantic versioning goes (in our use):
<EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
And as I understand it you're looking to go
<NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
Starting from 20
I'd ask the question - are there any big/disruptive changes people would want to bundle together to keep the semantic versioning and move to 5.x.y.z
I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
So, to be pedantic, and have a clearly defined vote, I'd change the vote to something like "Drop semantic versioning and continue from 20". And include your explanation about moving to
<NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
I would be ok to +1 that ^^^
-paul
-----Original Message-----
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Tuesday, March 5, 2024 4:02 PM
To: dev@cloudstack.apache.org; users@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
Regards.
________________________________
From: Paul Angus <pa...@apache.org>
Sent: Tuesday, February 20, 2024 15:55
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: RE: [VOTE] next version 20 instead of 4.20
Hi Daan,
From our wiki page:
-- Quote
For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
-- End quote.
Specifically:
The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
- Paul
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, February 20, 2024 10:05 AM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity
> to which it is addressed and may contain confidential and/or
> privileged information. If you are not the intended recipient, please
> delete the original message and any copy of it from your computer
> system. You are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited unless proper
> authorization has been obtained for such action. If you have received
> this communication in error, please notify the sender immediately.
> Although IndiQus attempts to sweep e-mail and attachments for viruses,
> it does not guarantee that both are virus-free and accepts no
> liability for any damage sustained as a result of viruses.
--
Daan
RE: [VOTE] next version 20 instead of 4.20
Posted by Paul Angus <pa...@apache.org>.
Hi Rohit, thank you
So to recap;
Semantic versioning goes (in our use):
<EXTREAMLY_DISRUPTIVE_CHANGES> . <NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
And as I understand it you're looking to go
<NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
Starting from 20
I'd ask the question - are there any big/disruptive changes people would want to bundle together to keep the semantic versioning and move to 5.x.y.z
I'm assuming not, so the move proposed is to drop semantic versioning and continue from 20, understanding that we would lose the mechanism to warn of very disruptive changes (for what it's worth).
I've no objection to it. The issue was, that reading the thread, people had different takes on what the change was, what would it do and what it meant. And also incorrect understandings of semantic versioning.
So, to be pedantic, and have a clearly defined vote, I'd change the vote to something like "Drop semantic versioning and continue from 20". And include your explanation about moving to
<NEW/IMPROVED_FEATURES> . <BUG_FIXES> . <SECURITY_FIXES>
I would be ok to +1 that ^^^
-paul
-----Original Message-----
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Tuesday, March 5, 2024 4:02 PM
To: dev@cloudstack.apache.org; users@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
Regards.
________________________________
From: Paul Angus <pa...@apache.org>
Sent: Tuesday, February 20, 2024 15:55
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: RE: [VOTE] next version 20 instead of 4.20
Hi Daan,
From our wiki page:
-- Quote
For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
-- End quote.
Specifically:
The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
- Paul
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, February 20, 2024 10:05 AM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity
> to which it is addressed and may contain confidential and/or
> privileged information. If you are not the intended recipient, please
> delete the original message and any copy of it from your computer
> system. You are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited unless proper
> authorization has been obtained for such action. If you have received
> this communication in error, please notify the sender immediately.
> Although IndiQus attempts to sweep e-mail and attachments for viruses,
> it does not guarantee that both are virus-free and accepts no
> liability for any damage sustained as a result of viruses.
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Rohit Yadav <ro...@shapeblue.com>.
As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
Regards.
________________________________
From: Paul Angus <pa...@apache.org>
Sent: Tuesday, February 20, 2024 15:55
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: RE: [VOTE] next version 20 instead of 4.20
Hi Daan,
From our wiki page:
-- Quote
For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
-- End quote.
Specifically:
The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
- Paul
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, February 20, 2024 10:05 AM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity
> to which it is addressed and may contain confidential and/or
> privileged information. If you are not the intended recipient, please
> delete the original message and any copy of it from your computer
> system. You are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited unless proper
> authorization has been obtained for such action. If you have received
> this communication in error, please notify the sender immediately.
> Although IndiQus attempts to sweep e-mail and attachments for viruses,
> it does not guarantee that both are virus-free and accepts no
> liability for any damage sustained as a result of viruses.
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Rohit Yadav <ro...@shapeblue.com>.
As I understand Daan's vote proposal and from the previous discussion thread, the current scheme that results in a release like 4.20.x.y would simply become 20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and "b" is only used for security releases (counter, starting with 0).
The voting thread is about "deciding to drop the 4 from our versioning scheme", wherein the next CloudStack version would become "20" instead of "4.20". By agreeing to drop the "4" I think we're effectively voting and agreeing that we'll not be breaking APIs. Some other opensource projects have done something similar too. Of course, this needs to be properly explained and documented both by a blog article and on the project wiki.
Paul - are you satisfied with the explanations and discussions, are you still blocking this vote thead or do you want to reconsider your vote?
Regards.
________________________________
From: Paul Angus <pa...@apache.org>
Sent: Tuesday, February 20, 2024 15:55
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: RE: [VOTE] next version 20 instead of 4.20
Hi Daan,
From our wiki page:
-- Quote
For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
-- End quote.
Specifically:
The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
- Paul
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, February 20, 2024 10:05 AM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity
> to which it is addressed and may contain confidential and/or
> privileged information. If you are not the intended recipient, please
> delete the original message and any copy of it from your computer
> system. You are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited unless proper
> authorization has been obtained for such action. If you have received
> this communication in error, please notify the sender immediately.
> Although IndiQus attempts to sweep e-mail and attachments for viruses,
> it does not guarantee that both are virus-free and accepts no
> liability for any damage sustained as a result of viruses.
--
Daan
RE: [VOTE] next version 20 instead of 4.20
Posted by Paul Angus <pa...@apache.org>.
Hi Daan,
From our wiki page:
-- Quote
For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
-- End quote.
Specifically:
The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
- Paul
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, February 20, 2024 10:05 AM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity
> to which it is addressed and may contain confidential and/or
> privileged information. If you are not the intended recipient, please
> delete the original message and any copy of it from your computer
> system. You are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited unless proper
> authorization has been obtained for such action. If you have received
> this communication in error, please notify the sender immediately.
> Although IndiQus attempts to sweep e-mail and attachments for viruses,
> it does not guarantee that both are virus-free and accepts no
> liability for any damage sustained as a result of viruses.
--
Daan
RE: [VOTE] next version 20 instead of 4.20
Posted by Paul Angus <pa...@apache.org>.
Hi Daan,
From our wiki page:
-- Quote
For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
In practice, feature releases will normally be an increment of the minor version number of the project. Feature releases that break backward compatibility will cause the major version number to be incremented. Bug fix releases will never increment anything except the patch number.
-- End quote.
Specifically:
The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next. This should be rare situation.
From this I can't see how we have broken the versioning. Have we introduced anything that meets the criteria above? Again, the term 'minor version' is an unfortunate one because it makes it sound like it wouldn’t contain big new features. However, that isn't the case, it can and should.
Also, I'd like to see fully laid out for the next few versions, how versioning is proposed to work, and what each part of x.y.z.n is then going to denote.
- Paul
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, February 20, 2024 10:05 AM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20
Vivek, we could, but the main idea is that we repair our versioning system and make clear how we are actually dealing with our current system, which is major - new , possibly breaking features minor - improvements and enhancements tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar <vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity
> to which it is addressed and may contain confidential and/or
> privileged information. If you are not the intended recipient, please
> delete the original message and any copy of it from your computer
> system. You are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited unless proper
> authorization has been obtained for such action. If you have received
> this communication in error, please notify the sender immediately.
> Although IndiQus attempts to sweep e-mail and attachments for viruses,
> it does not guarantee that both are virus-free and accepts no
> liability for any damage sustained as a result of viruses.
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Daan Hoogland <da...@gmail.com>.
Vivek, we could, but the main idea is that we repair our versioning
system and make clear how we are actually dealing with our current
system, which is
major - new , possibly breaking features
minor - improvements and enhancements
tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current
versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar
<vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity to
> which it is addressed and may contain confidential and/or privileged
> information. If you are not the intended recipient, please delete the
> original message and any copy of it from your computer system. You are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited unless proper authorization has been
> obtained for such action. If you have received this communication in error,
> please notify the sender immediately. Although IndiQus attempts to sweep
> e-mail and attachments for viruses, it does not guarantee that both are
> virus-free and accepts no liability for any damage sustained as a result of
> viruses.
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Daan Hoogland <da...@gmail.com>.
Vivek, we could, but the main idea is that we repair our versioning
system and make clear how we are actually dealing with our current
system, which is
major - new , possibly breaking features
minor - improvements and enhancements
tiny - urgent (security) fixes
and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current
versioning system.
On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar
<vi...@indiqus.com.invalid> wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
> >
> >
> > I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
> >
> >
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
> >
> > -----Original Message-----
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev <de...@cloudstack.apache.org>
> > Cc: users <us...@cloudstack.apache.org>
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> This message is intended only for the use of the individual or entity to
> which it is addressed and may contain confidential and/or privileged
> information. If you are not the intended recipient, please delete the
> original message and any copy of it from your computer system. You are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited unless proper authorization has been
> obtained for such action. If you have received this communication in error,
> please notify the sender immediately. Although IndiQus attempts to sweep
> e-mail and attachments for viruses, it does not guarantee that both are
> virus-free and accepts no liability for any damage sustained as a result of
> viruses.
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Vivek Kumar <vi...@indiqus.com.INVALID>.
Why not 5.0 ? Then it will be like 5.1, 5.2 in the future. Just asking ..!
> On 19-Feb-2024, at 10:49 PM, Paul Angus <pa...@angus.uk.com.INVALID> wrote:
>
> Hi Daan,
>
> Can you clarify what we are actually voting on please.
>
> In thread that is linked I've seen:
>
> "[the vote] will be to adjust to the semantic versioning system."
> - you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
>
> " drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
> - what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
>
> From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
>
>
> I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
>
>
>
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
>
> -----Original Message-----
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, February 19, 2024 12:50 PM
> To: dev <de...@cloudstack.apache.org>
> Cc: users <us...@cloudstack.apache.org>
> Subject: [VOTE] next version 20 instead of 4.20
>
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
> --
> Daan
--
This message is intended only for the use of the individual or entity to
which it is addressed and may contain confidential and/or privileged
information. If you are not the intended recipient, please delete the
original message and any copy of it from your computer system. You are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited unless proper authorization has been
obtained for such action. If you have received this communication in error,
please notify the sender immediately. Although IndiQus attempts to sweep
e-mail and attachments for viruses, it does not guarantee that both are
virus-free and accepts no liability for any damage sustained as a result of
viruses.
RE: [VOTE] next version 20 instead of 4.20
Posted by Paul Angus <pa...@angus.uk.com.INVALID>.
Hi Daan,
Can you clarify what we are actually voting on please.
In thread that is linked I've seen:
"[the vote] will be to adjust to the semantic versioning system."
- you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
" drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
- what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Monday, February 19, 2024 12:50 PM
To: dev <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Subject: [VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
RE: [VOTE] next version 20 instead of 4.20
Posted by Paul Angus <pa...@angus.uk.com.INVALID>.
Hi Daan,
Can you clarify what we are actually voting on please.
In thread that is linked I've seen:
"[the vote] will be to adjust to the semantic versioning system."
- you can't go to 20 AND keep semantic versioning. The act of going to 20 breaks semantic versioning [1].
" drop the 4 at version 20 and continue as usual with minor and patch level updates as we have in the past."
- what's supposed to come next ? in lieu of what would have been 4.21 will it be 21 ? is it going to be 20.1 then 20.2 ?
From the thread and how people are referring to 'minor versions', there is a misunderstanding as to what semantic versioning means. For our project its explained here [1]. Major versions meaning "probably going to break a load of people's stuff', with minor versions not breaking stuff (at least not on purpose). So I get calling them minor versions really underplays the changes it can hold.
I'm going to stick in a -1. Not as hard 'no' to any changes, but I think the vote should be on 'A change to the version numbering scheme' and then what is proposed properly laid out.
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section on versioning about 2/3 down)
-----Original Message-----
From: Daan Hoogland <da...@gmail.com>
Sent: Monday, February 19, 2024 12:50 PM
To: dev <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Subject: [VOTE] next version 20 instead of 4.20
LS,
This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted please reply to dev@.
As discussed in [1] we are deciding to drop the 4 from our versioning scheme. The result would be that the next major version will be 20 instead of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the versions are processed numerically there are no technical impediments.
+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)
As this is a lazy consensus vote any -1 should be accompanied with a reason.
[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
--
Daan
Re: [VOTE] next version 20 instead of 4.20
Posted by Abhishek Kumar <sh...@apache.org>.
+1
On Mon, 19 Feb 2024 at 18:20, Daan Hoogland <da...@gmail.com> wrote:
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
> counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning
> scheme. The result would be that the next major version will be 20
> instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
> and the versions are processed numerically there are no technical
> impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a
> reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
> --
> Daan
>
Re: [VOTE] next version 20 instead of 4.20
Posted by Andrija Panic <an...@gmail.com>.
+1
On Mon, 19 Feb 2024 at 13:50, Daan Hoogland <da...@gmail.com> wrote:
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be
> counted please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning
> scheme. The result would be that the next major version will be 20
> instead of 4.20, as it would be in a traditional upgrade. As 20 > 4
> and the versions are processed numerically there are no technical
> impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a
> reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
> --
> Daan
>
--
Andrija Panić