Skip to content

Instantly share code, notes, and snippets.

@jeffjirsa
Created November 18, 2016 23:35
Show Gist options
  • Save jeffjirsa/9bee187246ca045689c52ce9caed47bf to your computer and use it in GitHub Desktop.
Save jeffjirsa/9bee187246ca045689c52ce9caed47bf to your computer and use it in GitHub Desktop.
Sylvain - Cassandra 4.0 Proposal - Example
If you want to put some numbers on that, and taking a January start for 4.0
(I know it won't happen but bear with me), you get:
- We release 4.0 on January 2017 (it's both a "feature" and "testing"
release). We can call 3.0 the "stable" branch for the transition, which
thus enter it's critical bug only phase.
- From Februray to June, we release 4.1 -> 4.5 from trunk ("feature"), and
4.0.1 -> 4.0.5 from 4.0 with only bug fixes ("testing"). If a critical
fix on 3.0 comes, we cut a release.
- In July, we rotate, so we release 5.0, both a "feature" and "testing"
release from trunk, as well as 4.0.6 with bug fixes (but from that point
we call that one "stable"). The 3.0.X branch is now EOL.
- From August to December, we release 5.1 -> 5.5 from trunk ("feature"),
and 5.0.1 -> 5.0.5 from 5.0 with only bug fixes ("testing"). If we have
critical fix for 4.0.6, we release them when we find them (as 4.0.7, 4.0.8, ...).
- In January 2018, we rotate, so we release 6.0, both a "feature" and
"testing" release from trunk, as well as 5.0.6 with bug fixes (but from that point
we call that one "stable"). The previous "stable" branch, the 4.0.X one
is now EOL.
- Rinse and repeat.
Note that at any given time we have 2 releases on the monthly cadence plus
one on a critical hotfix only mode (so hopefully rather quiet), close to what we
have today (with tick-tock and 3.0 every month, and 2.2/2.1 on more of less
hotfix).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment