| We capture this as part of our release lifecycle document: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=132320437
We define releases from our “Beta” milestone onward as API-stable:
Beta - Definition / Expectations:
- Should be interface-stable, so that consumers do not have to incur any code changes on their end, as the release progresses from Alpha through EOL.
It seems unlikely that we would encounter a bug at a late release stage that would require breaking stability of a public API, and I don’t think we have an example of that at hand.
Since this is a [VOTE] thread, can I suggest discussion on release lifecycle to occur on a separate thread?
– Scott On Jul 5, 2024, at 4:58 PM, Josh McKenzie <jmcken...@apache.org> wrote:
I see the argument. In reality though we can never truly guarantee that something is API stable, only our intent to keep it so if at all possible, right?
On Wed, Jul 3, 2024, at 8:58 AM, Claude Warren, Jr wrote:
Because you do not know if the issues stopping the release will require an API change -- so is the API stable?
Perhaps we should consider a Milestone release. At least in some projects this is a way to provide a test bed with known issues that will be corrected before an RC.
How does that differ from beta in our lifecycle? API stable but a test bed to suss out issues like this.
On Mon, Jul 1, 2024, at 9:30 AM, Claude Warren, Jr via dev wrote:
Perhaps we should consider a Milestone release. At least in some projects this is a way to provide a test bed with known issues that will be corrected before an RC.
This came in after our vote, but we might also have a problem with performing schema changes after a full restart. Appears to only be if the entire cluster was shut down, according to the report. If it's true, this might affect anyone trying to restore from a backup. This would also be a blocker for me, if that's the case.
Jon
Thanks for confirming this, Blake. I agree that we should not knowingly ship new versions with severe bugs that cause the DB to crash, regression or not.
-1 from me as well
Looking at the ticket, I’d say Jon’s concern is legitimate. The segfaults Jon is seeing are probably caused by paxos V2 when combined with off heap memtables for the reason Benedict suggests in the JIRA. This problem will continue to exist in 5.0. Unfortunately, it looks like the patch posted is not enough to address the issue and will need to be a bit more involved to properly fix the problem.
While this is not a regression, I think Jon’s point about trie memtables increasing usage of off heap memtables is a good one, and anyway we shouldn’t be doing major releases with known process crashing bugs.
So I’m voting -1 on this release and will work with Jon and Benedict to get this fixed.
Thanks,
Blake
Blake or Benedict - can either of you speak to Jon's concerns around CASSANDRA-19668?
On Wed, Jun 26, 2024, at 12:18 AM, Jeff Jirsa wrote:
+1
Proposing the test build of Cassandra 5.0-rc1 for release.
sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
The vote will be open for 72 hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and no -1's.
|
