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 <j...@scclouds.com.br> Sent: Thursday, March 14, 2024 23:49 To: dev@cloudstack.apache.org <dev@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 <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 >> >>
