Re: [DISCUSS] Releases after 4.0
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 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 <
Re: [DISCUSS] Releases after 4.0
+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 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.
Re: [DISCUSS] Releases after 4.0
+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" 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 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
Re: [DISCUSS] Releases after 4.0
+1 to both the yearly cadence and the periodic publishing of bleeding edge snapshots. > On 5 Feb 2021, at 16:14, Benedict Elliott Smith 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" 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 >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 >>>
Re: [DISCUSS] Releases after 4.0
+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 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 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" 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 > > > >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. > >>> >
Re: [DISCUSS] Releases after 4.0
> 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. > +1 to branching off one release branch a year. Are we also trying to reach a consensus here that a release branch should be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 release branches plus trunk)? +1 to flexible dates. +1 to non-GA non-branched releases along the way. Jeremiah, I have nothing to add to your post. I think you did a fantastic job of combining how semver would work in combination Benedict's focus on cadence and reducing the community burden. It also helped highlight the different discussions to be had, that should be had separately. Thanks Benjamin for bringing it back to what was your original questions (sorry for the derail): > 1) What release cadence do we want to use for major/minor versions? > 2) How do we plan to ensure the quality of the releases? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Releases after 4.0
> > Are we also trying to reach a consensus here that a release branch should > be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 > release branches plus trunk)? 3 release branches make sense to me +1 On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever wrote: > > > 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. > > > > > +1 to branching off one release branch a year. > > Are we also trying to reach a consensus here that a release branch should > be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 > release branches plus trunk)? > > +1 to flexible dates. > > +1 to non-GA non-branched releases along the way. > > > Jeremiah, I have nothing to add to your post. I think you did a fantastic > job of combining how semver would work in combination Benedict's focus on > cadence and reducing the community burden. It also helped highlight the > different discussions to be had, that should be had separately. Thanks > Benjamin for bringing it back to what was your original questions (sorry > for the derail): > > > 1) What release cadence do we want to use for major/minor versions? > > 2) How do we plan to ensure the quality of the releases? > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Releases after 4.0
I'm +1 on 3 branches, and thus ~3 years of support. So in the transition, would we aim to keep 3.11 until after 4.0 and a successor are released? On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer wrote: > > > > > Are we also trying to reach a consensus here that a release branch should > > be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 > > release branches plus trunk)? > > > 3 release branches make sense to me +1 > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever wrote: > > > > > > 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. > > > > > > > > > +1 to branching off one release branch a year. > > > > Are we also trying to reach a consensus here that a release branch should > > be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 > > release branches plus trunk)? > > > > +1 to flexible dates. > > > > +1 to non-GA non-branched releases along the way. > > > > > > Jeremiah, I have nothing to add to your post. I think you did a fantastic > > job of combining how semver would work in combination Benedict's focus on > > cadence and reducing the community burden. It also helped highlight the > > different discussions to be had, that should be had separately. Thanks > > Benjamin for bringing it back to what was your original questions (sorry > > for the derail): > > > > > 1) What release cadence do we want to use for major/minor versions? > > > 2) How do we plan to ensure the quality of the 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
Re: [DISCUSS] Releases after 4.0
Err, to be clear: keep 3.11 until we have 3 other branches. On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams wrote: > > I'm +1 on 3 branches, and thus ~3 years of support. So in the > transition, would we aim to keep 3.11 until after 4.0 and a successor > are released? > > On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer > wrote: > > > > > > > > Are we also trying to reach a consensus here that a release branch should > > > be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 > > > release branches plus trunk)? > > > > > > 3 release branches make sense to me +1 > > > > > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever wrote: > > > > > > > > > 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. > > > > > > > > > > > > > +1 to branching off one release branch a year. > > > > > > Are we also trying to reach a consensus here that a release branch should > > > be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 > > > release branches plus trunk)? > > > > > > +1 to flexible dates. > > > > > > +1 to non-GA non-branched releases along the way. > > > > > > > > > Jeremiah, I have nothing to add to your post. I think you did a fantastic > > > job of combining how semver would work in combination Benedict's focus on > > > cadence and reducing the community burden. It also helped highlight the > > > different discussions to be had, that should be had separately. Thanks > > > Benjamin for bringing it back to what was your original questions (sorry > > > for the derail): > > > > > > > 1) What release cadence do we want to use for major/minor versions? > > > > 2) How do we plan to ensure the quality of the 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
Re: [DISCUSS] Releases after 4.0
Perhaps on my third try... keep three branches total, including 3.11: 3.11, 4, next. Support for 3.11 begins ending after next+1, is what I'm trying to convey. On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams wrote: > > Err, to be clear: keep 3.11 until we have 3 other branches. > > On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams wrote: > > > > I'm +1 on 3 branches, and thus ~3 years of support. So in the > > transition, would we aim to keep 3.11 until after 4.0 and a successor > > are released? > > > > On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer > > wrote: > > > > > > > > > > > Are we also trying to reach a consensus here that a release branch > > > > should > > > > be supported for ~3 years (i.e. that we are aiming to limit ourselves > > > > to 3 > > > > release branches plus trunk)? > > > > > > > > > 3 release branches make sense to me +1 > > > > > > > > > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever wrote: > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > +1 to branching off one release branch a year. > > > > > > > > Are we also trying to reach a consensus here that a release branch > > > > should > > > > be supported for ~3 years (i.e. that we are aiming to limit ourselves > > > > to 3 > > > > release branches plus trunk)? > > > > > > > > +1 to flexible dates. > > > > > > > > +1 to non-GA non-branched releases along the way. > > > > > > > > > > > > Jeremiah, I have nothing to add to your post. I think you did a > > > > fantastic > > > > job of combining how semver would work in combination Benedict's focus > > > > on > > > > cadence and reducing the community burden. It also helped highlight the > > > > different discussions to be had, that should be had separately. Thanks > > > > Benjamin for bringing it back to what was your original questions (sorry > > > > for the derail): > > > > > > > > > 1) What release cadence do we want to use for major/minor versions? > > > > > 2) How do we plan to ensure the quality of the 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
