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: d...@cloudstack.apache.org <d...@cloudstack.apache.org> Cc: users@cloudstack.apache.org <users@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: users@cloudstack.apache.org Cc: d...@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 <d...@cloudstack.apache.org> > > Cc: users <users@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
