I’d like to suggest an option similar to what Jeremiah described and that would basically follow the Ubuntu LTS release model [1], but with shorter time periods. The idea would be to do a stable release every 6 months with 1 year bug fixing support. At the same time, every third stable release will serve as a LTS release and will be supported for 2 years.
Have a look at the following gist for illustration: https://gist.github.com/spodkowinski/b9659169c73de3231f99bd17f74f5d1f As you can see, although the support periods are relatively long, only 3 releases must be supported at the same time, which should be comparable to what is done now. At the same time, we also keep doing monthly releases, but they will only serve as a milestone for the next stable release. Call them “dev”, “beta”, “testing” or whatever you like. Users will be able to start developing for those dev releases and deploy to production with the next standard or LTS release, after development is finished. Another option for users would be to start a project with a standard release and later settle down on a LTS release for maintenance only. It's pretty flexible from a user perspective, easy to understand and not too much effort to implement from the development side. On Sat, Nov 19, 2016 at 12:49 AM, 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/0b2ca82eb8c1235a4e44a406080729 > be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E > [2]: https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b > 2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E > [3]: https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538ee > f34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E > [4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf > [5]: https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b2 > 03b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E > > > > >
