+1 from me on the yearly cadence fwiw. The space this project is in (infra software) is directly at odds for many users' preferred release cadence (preferably never or bugfix only for existing / stable projects) compared to how fast the NoSQL / database ecosystem is evolving; once a year seems to strike a reasonable balance between the various constituents.
On Fri, Feb 5, 2021 at 9:58 AM Benjamin Lerer <benjamin.le...@datastax.com> wrote: > 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 > > > > >
