Thanks for your responses. I had some offline discussions with different persons to gather more feedback on the current discussion. The people I talked to appeared to be in favor of one supported release every year as Benedict initially suggested. The advantages mentioned were: * it is long enough to allow us to have a significant amount of work done * if some work slip to the next release it will only be delayed for one year * it does not create too much burden in term of release maintenance * it provides some certainty to the community
I believe that there is an appetite for the bleeding edge snapshots where we do not guarantee stability and that the semver discussion is not finished yet but I would like us to let those discussions go for some follow up threads. My goal with this thread was to reach an agreement on a release cadence for the version we will officially support after 4.0. My impression is that most people agree with *one release every year* so I would like to propose it as our future release cadence. Your feedback is welcome. On Thu, Jan 28, 2021 at 6:45 PM Jeremiah D Jordan <jeremiah.jor...@gmail.com> wrote: > I think we are confusing things between minor vs patch. Can we talk about > branch names? > > I think we can agree on the following statements? > > Releases made from stable maintenance branches, > cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit > features being added to them and should be mostly bug fix only. > > New features will be developed in trunk. > > Now I think the thing under discussion here is “how often will we cut new > maintenance branches from trunk” and also “how long will we maintain those > branches" > > I would definitely like to see the project able to release binaries from > trunk more often then once a year. As long as we keep our quality goals in > line post 4.0 GA I think this is possible. > > > I'd like to see us have three branches: life support (critical fixes), > stable (fixes), and development. Minors don't fit very well into that IMO. > > If we want to go with semver ideas, then minors fit perfectly well. > Server doesn’t meant you make patch releases for every version you have > ever released, it is just a way of versioning the releases so people can > understand what the upgrade semantics are for that release. If you dropped > support for some existing thing, you need to bump the major version, if you > added something new you bump the minor version, if you only fixed bugs with > no user visible changes you bump the patch version. > > > I suppose in practice all this wouldn't be too different to tick-tock, > just with a better state of QA, a higher bar to merge and (perhaps) no > fixed release cadence. This realisation makes me less keen on it, for some > reason. > > I was thinking something along these lines might be useful as well. > > I could see a process where we cut new maintenance branches every X time, > ~1 year?, 6 months?, we would fix bugs and make patch releases from those > maintenance branches. > We would also cut releases from the development branch (trunk) more > often. The version number in trunk would be updated based on what had > changed since the last release made from trunk. If we dropped support for > something since the last release, bump major. If we added new features > (most likely thing), bump minor. > > So when we release 4.0 we cut the cassandra-4.0 maintenance branch. We > make future 4.0.1 4.0.2 4.0.3 releases from this branch. > > Trunk continues development, some new features are added there. After a > few months we release 4.1.0 from trunk, we do not cut a cassandra-4.1 > branch. Development continues along on trunk, some new features get in so > we bump the version in the branch to 4.2.0. A few months go by we release > 4.2.0 from trunk. Some bug fixes go into trunk with no new features, the > version on the branch bumps to 4.2.1, we decide to make a release from > trunk, and only fixes have gone into trunk since the last release, so we > release 4.2.1 from trunk. > > We continue on this way releasing 4.3.0, 4.4.0, 4.4.1 …. We decide it is > time for a new maintenance branch to be cut. So with the release of 4.5.0 > we also cut the cassandra-4.5 branch. This branch will get patch releases > made from it 4.5.1 4.5.2 4.5.3. > > Trunk continues on as 4.6.0, 4.7.0, 4.8.0 …. At some point the project > decides it wants to drop support for some deprecated feature, trunk gets > bumped to 5.0.0. More releases happen from trunk 5.0.0, 5.1.0, 5.2.0, 5.2.1 > development on trunk continues on. Time for a new maintenance branch with > 5.3.0 so cassandra-5.3 gets cut... > > This does kind of look like what we tried for tick/tock, but it is not the > same. If we wanted to name this something, I would call it something like > "releasable trunk+periodic maintenance branching”. This is what many > projects that release from trunk look like. > > -Jeremiah > > > > On Jan 28, 2021, at 10:31 AM, Benedict Elliott Smith < > bened...@apache.org> wrote: > > > > But, as discussed, we previously agreed limit features in a minor > version, as per the release lifecycle (and I continue to endorse this > decision) > > > > On 28/01/2021, 16:04, "Mick Semb Wever" <m...@apache.org> wrote: > > > >> if there's no such features, or anything breaking compatibility > >> > >> What do you envisage being delivered in such a release, besides bug > >> fixes? Do we have the capacity as a project for releases dedicated to > >> whatever falls between those two gaps? > >> > > > > > > All releases that don't break any compatibilities as our documented > > guidelines dictate (wrt. upgrades, api, cql, native protocol, etc). > Even > > new features can be introduced without compatibility breakages (and > should > > be as often as possible). > > > > Honouring semver does not imply more releases, to the contrary it is > just > > that a number of those existing releases will be minor instead of > major. > > That is, it is an opportunity cost to not recognise minor releases. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
