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
