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
