+1 to both yearly release and periodic snapshots. As far as timing goes, I would like to avoid picking a specific date for release, and instead choose something like "the first Wednesday of May" or something.
On Fri, Feb 5, 2021 at 10:20 AM Sam Tunnicliffe <s...@beobal.com> wrote: > > +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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
