I have been thinking about how we can get better with our release cadence. I feel like we have slowed to a crawl and not been as good as we should about how we release. Our last Major release was in March and we haven't had a real release since. Moving forward I would like to see us get on a more consistent cadence and provide smaller releases that can be more easily digested by the community. It's my hope that we can get to a cadence where we are doing releases every 4 to 6 weeks, we are releasing in such a way that not all releases all required (e.g. if you are on 4.0 you don't need 4.1, you can just install 4.2), and we are more deliberate about what we put into a release.
I think we can accomplish this by using our release branches better. For each major release we will cut a release branch from master (e.g. 4.x) and then we will use cherry-picking to add new features and bug fixes to that release. This means that if 4.0 has been released and you want to get your feature/bug fix in 4.1, you will first submit your PR to master and then cheery pick your squash merged commit to the 4.x branch which we will use to create the 4.1 release. I think we should allow either the contributor or the committer (who is merging the PR) to suggest if a feature goes into the release branch, and if we disagree we can take it to the list. If we decide that every PR to master also goes into 4.1 then so be it, but at least we are making a conscious decision of what goes into the next release. This will allow us to not be so worried about what we are merging into master and how that will affect our next release. According to our 6 week cadence we will cut a new release from the current feature branch and put that up for a vote. These releases will be small and testable enough that we can get feedback quickly and move from RC to release in a short time. If a release has too many issues then we may end up deciding to skip that minor release in favor of the next one, hopefully this does not happen very often if at all. Once a breaking change is introduced to master which will require a new major release, we will create a new major release branch from master (which will mean a new release manager). We will then repeat the same process with the new release branch, etc, etc. As for LTS we will provide support for the latest major release plus the one previous. So, once we release 4.0 we will support 4.0 and 3.1. Any security issues that arise will -- if present -- be applied to each of these versions. Once 4.1 is released we will support 4.1 and 3.1, etc, etc. Please let me know if you have any thoughts on this plan. If there are no major objections I would like to try this with 4.x with the idea that we will adjust how we do things as necessary. We need to get better at releasing and something needs to change, hopefully this can get us going in the right direction. Thanks, Dave TL;DR - I am proposing a 6 week release cycle using cherry-picks to our release branch to control what goes into a minor release. Major releases will be cut from master as necessary - such as if there is a breaking change that is introduced.
