This has definitely been a confusing topic in the past, I completely agree Benedict. Glad you brought this up.
I'm 100% on board with 5.0 after 4.0. On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith <bened...@apache.org> wrote: > As a brief side-step on the topic only of versioning (which no doubt will > cause enough consternation), I personally endorse streamlining it. We have > not had a consistently meaningful convention on this, at any point, and we > made it even worse in the 3.x line. There's no real difference between > 1.2->2.0, 2.0->2.1, or 3.0->3.11 and 3.11->4.0; let's admit this and go > straight to 5.0 for our next feature release, with 4.1 our first patch > release of the 4.x line. > > > On 08/10/2019, 21:36, "Scott Andreas" <sc...@paradoxica.net> wrote: > > Re: "How can we decide that *all* new features are suppose to go into > trunk only, if we don’t even have an idea about the upcoming release > schedule?" > > This is a great question. My understanding of the intent of the > document is that new features are generally expected to land in trunk, with > an exception process defined for feature backports. I think that's a > reasonable expectation to start with. But I also agree with you that it's > important we evolve a way to discuss and agree up on release scope - this > was the focus of my slides at NGCC. I would love to discuss this on a > separate thread. > > Re: “Bug fix releases have associated new minor version.” > "Patchlevel version" might be more in keeping with our current > convention. > > Re: "We should give users a way to plan, by having EOL dates" > Incorporating EOL dates into our release management / planning is a > great idea. > > Would you be willing to rephrase your comments in the form of proposed > edits to the document? > > – Scott > > ________________________________________ > From: Stefan Podkowinski <s...@apache.org> > Sent: Tuesday, October 8, 2019 1:22 PM > To: dev@cassandra.apache.org > Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle > > From the document: > > General Availability (GA): “A new branch is created for the release > with > the new major version, limiting any new feature addition to the new > release branch, with new feature development will continue to happen > only on trunk.” > Maintenance: “Missing features from newer generation releases are > back-ported on per - PMC vote basis.” > > We had a feature freeze before 4.0, which showed that people have > different views on what actually qualifies as a feature. It doesn’t > work > without defining “feature” in more detail. Although I’d rather avoid to > have this in the document at all, since I don’t think this is getting > us > anywhere, without having a clearer picture on the bigger context in > which release are going to happen in the future, starting with release > cadence and support periods. How can we decide that *all* new features > are suppose to go into trunk only, if we don’t even have an idea about > the upcoming release schedule? > > “Bug fix releases have associated new minor version.” > > So the next bug fix version will be 4.1? There will be no minor feature > releases like we did with 3.x.0/2.x.0? > > Deprecated: > "Through a dev community voting process, EOL date is determined for > this > release.” > “Users actively encouraged to move away from the offering.” > > We should give users a way to plan, by having EOL dates that may be > months or years ahead in the future. We did this with 3.0 and 2.x, > which > would be all “deprecated” a long time ago with the new proposal. > > Deprecated: “Only security vulnerabilities and production-impacting > bugs > without workarounds are addressed.” > > Although devs will define their own definition of “production-impacting > bugs without workarounds” in any way they need, I don’t think we should > have this in the document. It’s okay to use EOLed releases and we > should > not prevent users from contributing smaller fixes, performance > improvements and useful enhancements for minor feature releases. > > On 08.10.19 20:00, sankalp kohli wrote: > > Hi, > > We have discussed in the email thread[1] about Apache Cassandra > Release > > Lifecycle. We came up with a doc[2] for it. We have finalized the doc > > here[3] Please vote on it if you agree with the content of the doc > [3]. > > > > We did not proceed with the previous vote as we want to use > confluence for > > it. Here is the link for that[4]. It also mentions why we are doing > this > > vote. > > > > Vote will remain open for 72 hours. > > > > Thanks, > > Sankalp > > > > [1] > > > https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E > > [2] > > > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw > > [3] > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > > Attachments area > > [4] > > > https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E > > < > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#heading=h.633eppni91tw > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
