As we march towards version 1.0
I think we should move to a Google chrome style releases. Meaning we will have 4 branches going.
Stable channel
This will live in the "stable" branch, every release will be tagged. First stable release will be 1.0.0
We will only backport urgent fixes between releases (on a case by case basis).
So:
1.0.0 will be the first release
1.0.1 (which we hopefully will not need will only contain security fixes, urgent performance fixes, and egregious bug fixes)
Beta channel
This will live in the "beta" branch, once a week we will take code from master and merge it in. Each release will be tagged using odd numbers
1.1.0 (week 1)
1.1.1 (week 2)
During the week we will only backport stuff that we backport to stable. We will keep to a rigid weekly schedule here.
Tests passed channel
The branch already exists, we commit all our work into "master" once our internal test suite passes we merge in master.
How often will we release stable?
I think we should stick to a regular release cycle, a new stable release every 8 weeks. We should let "stable" bake in beta for a week before merging into the stable branch, this will allow us to at least catch major regressions and ensure plugins are good.
Isn't this a lot of extra work?
Our current process already "sort-of" has beta and tests-passed. However instead of tagging master we will now have a proper branch for beta, which is both simpler and safer.
The new structure will also simplify Discourse docker which you can set to track whichever release channel you want by simply tracking a branch.
So, the only real extra work will be the occasional backport of security fixes into stable. It is an unavoidable as we will be maintaining a stable release.
What about email notifications for new releases?
We need to amend our version checker to check what branch you are on in order to notify you. At the moment is it notifying on every beta release, which clearly only makes sense if you are tracking the beta channel.
Why I like this model?
By having a "stable" channel, we can ensure we are not stuck supporting "stable" releases that are old. Our support story for Discourse 1.0.0 in 2 months becomes, first upgrade to 1.2.0 and then we can support you.
This model allows us to continue working the way we do now, without needing any drastic changes. I would loath supporting very old versions of Discourse. I also understand that some only want to upgrade once in a while.
Question? Suggestions? Grievances?