Can we please stick to the vote here. We can always change the documentation as it will evolve over time.
> On Oct 8, 2019, at 2:57 PM, Joshua McKenzie <jmcken...@apache.org> wrote: > > 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 >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
