It probably warrants a separate discussion about how we version. Also, robust +1 to what you said here bes and haddad ;)
On Tue, Oct 8, 2019 at 5:31 PM Jon Haddad <j...@jonhaddad.com> wrote: > 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 > > > > >
