+1 to both the yearly cadence and the periodic publishing of bleeding edge snapshots.
> On 5 Feb 2021, at 16:14, Benedict Elliott Smith <bened...@apache.org> wrote: > > +1 > > +1 also to mixing this with an experiment on regular "releasable" (without > API stability) snapshots from trunk. > > On 05/02/2021, 16:07, "Joshua McKenzie" <jmcken...@apache.org> wrote: > > +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 >>> >>> >> > > > > --------------------------------------------------------------------- > 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
