RE: [VOTE] next version 20 instead of 4.20
Hi Rohit, thank you So to recap; Semantic versioning goes (in our use): . . . And as I understand it you're looking to go . . 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 . . I would be ok to +1 that ^^^ -paul -Original Message- From: Rohit Yadav Sent: Tuesday, March 5, 2024 4:02 PM To: d...@cloudstack.apache.org; users@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 Sent: Tuesday, February 20, 2024 15:55 To: d...@cloudstack.apache.org Cc: 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 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 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 wrote: > > > > Hi Daan, > >
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 Sent: Tuesday, February 20, 2024 15:55 To: d...@cloudstack.apache.org Cc: 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 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 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 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
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 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 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 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 > > Sent: Monday, February 19, 2024 12:50 PM > > To: dev > > Cc: users > > 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 (k
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 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 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 > > Sent: Monday, February 19, 2024 12:50 PM > > To: dev > > Cc: users > > 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
Re: [VOTE] next version 20 instead of 4.20
Paul, On Mon, Feb 19, 2024 at 6:21 PM Paul Angus 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]. We are using a crooked semantic versioning system and that is entirely due to maintaining the 4 in our versioning scheme. We have been changing and adding major features on updating the second number (20 to be). We have been using the third number for bug fixes and minor enhancements. And we have been using the fourth number for emergency security fixes. So we are not maintaining semantic versioning but going to semantic versioning by repairing our system of versioning. You could say this is a minor bugfix. > > " 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 ? Yes, exactly. Except for dropping the 4, nothing will change. > > 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 > Sent: Monday, February 19, 2024 12:50 PM > To: dev > Cc: users > 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 -- Daan
Re: [VOTE] next version 20 instead of 4.20
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 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 > Sent: Monday, February 19, 2024 12:50 PM > To: dev > Cc: users > 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.
Re: [VOTE] next version 20 instead of 4.20
+1 On 2024-02-19 15:09, Andrija Panic wrote: +1 On Mon, 19 Feb 2024 at 13:50, Daan Hoogland wrote: 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
RE: [VOTE] next version 20 instead of 4.20
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 Sent: Monday, February 19, 2024 12:50 PM To: dev Cc: users 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
Re: [VOTE] next version 20 instead of 4.20
+1 On Mon, 19 Feb 2024 at 13:50, Daan Hoogland wrote: > 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 > -- Andrija Panić
Re: [VOTE] next version 20 instead of 4.20
+1 Op 19/02/2024 om 13:49 schreef Daan Hoogland: 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
RE: [VOTE] next version 20 instead of 4.20
+1 -Original Message- From: Daan Hoogland Sent: Monday, February 19, 2024 1:50 PM To: dev Cc: users 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
[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
