I am a bit scared of a continuous delivery approach for a database due to the lack of guarantee on the APIs and protocols as you mentioned. On the other hand an annual major release cadence seems a bit too inflexible for me. It makes sense to me to ensure that we release at least one major version per year, nevertheless I believe that if we see that a significant amount of work has been released (for example 3 or 4 CEPs) we should allow ourselves to cut a release sooner. Making an official release would force us to go beyond our normal testing ensuring that we did not introduce new defects that our tests could have missed. Interaction between features is often a weak spot from the testing point of view.
What do you think? On Thu, Jan 28, 2021 at 1:25 PM Benedict Elliott Smith <bened...@apache.org> wrote: > We have had a very problematic history with release versioning, such that > our users probably think the numbers are meaningless. > > However, in the new release lifecycle document (and in follow-up > discussions around qualifying releases) we curtail _features_ once a > release is GA, and also stipulate that a new major version is associated > with a release. > > This happens to accord with my preference, namely that we eliminate the > concept of a minor release in semver terms. We have feature releases and > patch releases. i.e., 4.0's first bug fix release is 4.1, and in a year we > ship 5.0. There has been support voiced for this in a couple of forums > (including on this list back in 2019), but it was perhaps never fully > discussed/settled. > > > Why make a release at a fixed time each year? > > Stable-trunk is more popularly associated with Continuously Delivered > (CD) codebases > > We need to pick some points in time to provide stability/patch support > for, and an annual cadence provides some certainty to the community. > Perhaps it wouldn't make sense if we aim for true continuous delivery of > trunk. However, there is value in flexibility to experiment/revisit > decisions before committing to APIs and feature behaviours long term. By > providing continuous delivery of builds that do not guarantee API stability > for new features/APIs, users that are able to accept some small risk in > this regard (e.g. during development, or where they do not intend to use > the new features) may still benefit from access to high quality releases > quickly, and the project gets more rapid feedback. > > Perhaps we can have a flexible approach though, wherein we have continuous > delivery of release candidates, and on arbitrary timelines cut releases > that create API-stability points, and periodically nominate such releases > to receive 3+ years of support. > > > > On 28/01/2021, 11:42, "Mick Semb Wever" <m...@apache.org> wrote: > > > I'd like to pair this with stricter merge criteria, so that we > maintain a > ~shippable trunk, [snip]. We might have to get happy with reverting > commits > that break things. > > > Yes and yes! The work we have done, started on, and undercovered in > the 4.0 > Quality Testing Epics should continue. > > Our CI systems have also improved. Folk are using both circleci and > ci-cassandra, and i think the combination brings an advantage. Though > there's still a lot to do. CircleCI doesn't cover everything, and > with ci-cassandra there are a few things still to do. For example: > arm64, > jmh, jacoco, dtest-large-novnode, and putting dtest-upgrade into the > pipeline. Jira tickets exist for these. Another issue we have is > reliably > identifying flaky tests and test history. All test results and logs > are now > getting stored in nightlies.a.o, so the data is there to achieve it, > but > searching it remains overly raw. > > If such efforts continue, as they have, we should definitely be able to > avoid repeating the feature freeze requirement. > > > > My preference is for a simple annual major release cadence, with > minors > as necessary. This is simple for the user community and developer > community: support = x versions = x years. > > This raises a number of questions for me. > > Why make a release at a fixed time each year? > The idea of one major release a year contradicts in practice any > efforts > towards a stable-trunk. Stable-trunk is more popularly associated with > Continuously Delivered (CD) codebases. Yearly releases are not quite > that, > and I can't see a stricter merge criteria compensating enough. I have > put > effort into the release process, and encouraged the community to have > more > active release managers, so that when we need a release we can get > one. We > should be looking into cutting patch releases as often as possible. > > For how many years shall we support major versions? > Currently we maintain three release branches, plus one limited to > security > issues, and the oldest has been supported for 5 years. I think 5 years > is > too long for the current community and would suggest bringing it down > to 3 > years. The project is maturing, and along with efforts towards a > stable-trunk, I would expect upgrades to be getting easier. Asking > users to > upgrade at least once every three years shouldn't be a big deal for an > OSS > project. > > > > I understood us to have agreed to drop semver, because our > major/minor > history has been a meaningless distinction… > > > I am not sure that I understand that point, is there reference to this > agreement? > Not releasing minor versions doesn't mean we drop semver, we still > have the > three numbers there in our versions. In your first reply you wrote > that we > would do "minors as necessary", what were your thoughts on what a > minor was > there? Was it just a relabelling of patch versions? > > Now that we have our Release Lifecycle guidelines defined, which > included > discussions on compatibility issues, isn't it a good time to also > define > what "incompatible API changes" is for us? > > If we define "incompatible API changes" then each release should be > simple > enough to know whether it is going to be a major or minor. This also > comes > back to our support window, if we have a three year support window and > only > yearly major versions, does that not mean we are then asking users to > perform three upgrades every three years? > > I am pretty sure I would favour defining what "incompatible API > changes" > means for us, and aim for only one major every three years but let the > PMC > make exceptions as we go along when we see fit, knowing the cost the > exception comes with. > > We are already getting better at identifying what incompatibilities > are, as a > requirement we have put on ourselves with the Release Lifecycle > guidelines. > And I assume that pushing for a stable-trunk effectively implies some > semver like strategy, allowing us to re-use our identification of > incompatibilities. In short, if we are making ourselves better at > identifying incompatibilities (because of the Release Lifecycle), why > would > we not re-use that to benefit the user? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
