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 <rohit.ya...@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 <gutoveron...@apache.org>
Sent: Wednesday, March 6, 2024 4:00:30 AM
To: dev@cloudstack.apache.org <dev@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 <rohit.ya...@shapeblue.com>
Sent: Tuesday, March 5, 2024 4:02 PM
To: dev@cloudstack.apache.org; us...@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 <pau...@apache.org>
Sent: Tuesday, February 20, 2024 15:55
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
Cc: us...@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 <daan.hoogl...@gmail.com>
Sent: Tuesday, February 20, 2024 10:05 AM
To: us...@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 <vivek.ku...@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 <p...@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 <daan.hoogl...@gmail.com>
Sent: Monday, February 19, 2024 12:50 PM
To: dev <dev@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
