> 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?
