I think the monthly releases are important, otherwise releases become an “event”. The monthly releases mean they are just a normal thing that happens. So I like any of 3/4/5.
Sylvain's proposal sounds interesting to me. My only concern would be with making sure we label things very clearly so that users understand which branch is the current “stable” branch. The switch from “testing” to “stable” seems like a place that could cause confusion, but as long as we label everything well I think we can handle it. That being said, I think it would be a good addition to the current model making the “wait for .6 for stable” more explicit in the release plan, since this is what many users already do on their own. So I think I like Option 3 most of them. It keeps a monthly cadence, it makes explicit which branch we think is stable, and it keeps the number of active branches manageable. -Jeremiah > On Nov 18, 2016, at 5:49 PM, Jeff Jirsa <jeff.ji...@crowdstrike.com> wrote: > > With 3.10 voting in progress (take 3), 3.11 in December/January (probably?), > we should solidify the plan for 4.0. > > I went through the archives and found a number of proposals. We (PMC) also > had a very brief chat in private to make sure we hadn’t missed any, and here > are the proposals that we’ve seen suggested. > > Option #1: Jon proposed [1] a feature release every 3 months and bugfixes for > 6 months after that. > Option #2: Mick proposed [2] bimonthly feature, semver, labelling release > with stability/quality during voting, 3 GA branches at a time. > Option #3: Sylvain proposed [3] feature / testing / stable branches, Y > cadence for releases, X month rotation from feature -> testing -> stable -> > EOL (X to be determined). This is similar to an Ubuntu/Debian like release > schedule – I asked Sylvain for an example just to make sure I understood it, > and I’ve copied that to github at [4]. > Option #4: Jeremiah proposed [5] keeping monthly cadence, and every 12 months > break off X.0.Y which becomes LTS (same as 3.0.x now). This explicitly > excludes alternating tick/tock feature/bugfix for the monthly cadence on the > newest/feature/4.x branch. > Option #5: Jason proposed a revision to Jeremiah’s proposal such that > releases to the LTS branches are NOT tied to a monthly cadence, but are > released “as needed”, and the LTS branches are also “as needed”, not tied to > a fixed (annual/semi-annual/etc) schedule. > > Please use this thread as an opportunity to discuss these proposals or feel > free to make your own proposals. I think it makes sense to treat this like a > nomination phase of an election – let’s allow at least 72 hours for > submitting and discussing proposals, and then we’ll open a vote after that. > > - Jeff > > [1]: > https://lists.apache.org/thread.html/0b2ca82eb8c1235a4e44a406080729be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E > [2]: > https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E > [3]: > https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538eef34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E > [4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf > [5]: > https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b203b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E > > > >
