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 <daan.hoogl...@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 <rohit.ya...@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 <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 > > > > -- Daan
