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 > >
