# Release schedule post version 1.0

(Sam Saffron) #1

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.

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?

What comes after Version 1?
Please don't pressure self-installers to be on Beta branch
Version 1.0.1 not advertised by Discourse hub
Need a roadmap for post-1.0 development
MathJax plugin could not find module discourse/lib/load-script
How to upgrade from a beta version to a stable release?
There was a problem sending another activation email
How to make bug reports for Discourse
Information about differences between beta builds and release
Logo url won't reset due to Ghostery
Three branches are killing the translation workflow, how to deal with that?
When is something backported to Stable?
(Bill Ayakatubby) #2

Looks good overall, but what’s the thinking behind odd/even minor version numbers for beta/stable? It feels very “magic numbers” to me. Granted, most versioning is, but this seems especially so. Why not use semantic versioning instead and use trailing labels to indicate unstable (-beta, -canary, -tests-passed)?

(Sam Saffron) #3

1.0.0, 1.0.1 etc is all semver compliant … I guess the argument here is to have beta already sit at version 1.1 and wack -beta at the end. I don’t mind, fine with that.

Note, we will not be tagging canary or tests passed

(Bill Ayakatubby) #4

No worries, I was just curious about the rationale.

One other question. You wrote that beta will have code merged in from master. Shouldn’t that be from canary?

(Sam Saffron) #5

Nope I think master is correct here, canary is fixed to once a day, we often want to tag beta at arbitrary point during the day.

(Bill Ayakatubby) #6

OK, that makes sense, but then wouldn’t it be better to merge from tests-passed? Let me explain my overall thinking.

In my last reply, my thinking was that beta should be merged from canary instead of master so that you wouldn’t run into the odd circumstance of beta containing features/fixes that don’t exist in canary. But your workflow is different, so no big deal. Your code, your rules.

Now my thinking is that you’d want to merge from tests-passed instead of master, so that at least you know it won’t be completely broken. Again, though, your code, your rules. Just trying to understand and be helpful.

(InsaneMosquito) #7

Will this be an immediate “We only support current stable”? My assumption is that, at some point, a breaking change will have to be introduced for some reason. Does this give the user wiggle room to upgrade?

If someone is only tracking stable, immediately dropping support when the new version comes out is rather abrupt. For someone tracking beta, they should have time to make changes to update their code and be prepared. For stable, there is a decent chance they won’t even be aware of upcoming changes - especially as Discourse continues to become more prevalent and less technical users install it.

Would it be feasible to support current and current - 1 stable releases? Assuming stable releases are every 8 weeks, that means a version of Discourse would be supported for roughly a two month window.

(Sam Saffron) #8

I am very reticent to commit to backporting security fixes to stable + stable -1. It worries me to commit to this level of work now.

(InsaneMosquito) #9

Fair enough. I suppose that raises the question, how can users on Stable be warned that a new version will be available soon? Could some kind of communication/alert/notification be made while the beta is baking for a week warning them of an impending update? Maybe it could link them to the change log for them peruse.

(Dave McClure) #10

Would you encourage some folks to continue to live on the edge and stay on the beta or canary stream?

What if they want to switch streams?

If you have an install tracking the Canary branch and later decide that you want to be on Stable, will it be safe to just switch the docker YAML file? Or is it likely that a migration in Canary that’s not on Stable yet will make this kind of “rolling back” error prone?

Which branch will meta be tracking?

(Manthan Mallikarjun) #11

Why not follow git flow? A successful Git branching model » nvie.com

(Sam Saffron) #12

For us and all our customers we will strongly encourage at least being on beta. Meta is likely to be on various snapshots of latest-stable, just as it is now.

It is unsafe switching from beta/cannery to stable, we can not guarantee backwards compatibility of DB schema, it would have a severe cost. You can switch to stable from cannery just prior to a release.

(Dave McClure) #13

There isn’t really anything magical about git flow. We adopted it on one project, and quickly adapted it to a model that better suited our needs.

I think the branching model proposed above makes a lot of sense for discourse.

I kind of figured that would be the case

At some point, it might be worth exposing the database version, and having the update actually prevent one from attempting to run an update that would result in an incompatibility.

(Sam Saffron) #14

Yes totally agree there.

(Manthan Mallikarjun) #15

Its not really magical, but its really neat and easy to follow. Anyways, thats just what im used to.

Cant wait till the 1.0 launch!

(Tuan Anh Tran) #16

What abt those who currently use master. Do we need to do anything?

(Sam Saffron) #17

As long as you do

cd /var/docker
git pull
vim containers/app.yml <-- ensure no version in params
./launcher rebuild app


You should be fine.

(Régis Hanol) #18

Stable and beta are needed post-V1 but I’m not sure I see/understand the rationale behind canary when you have test passed?

I get that one day of testing might allow us to fix some bugs, but if people choose to be on bleeding edge, I’m not sure it’s worth the hassle to have 2 branches for that.

EDIT: or maybe we should not advertise about test-passed and keep it only internal.

(Sam Saffron) #19

The point actually is that canary is zero effort for us … it will just tick over automatically. and is ever so slightly safer than being on the bleeding edge.

Anyway don’t feel that strongly about the canary thing, we can skip it for now.

(Régis Hanol) #20

I actually meant mental effort.

If there’s only 1 branch, then being on bleeding edge is easy, you use that branch.
But if there are 2 branches, then you will have to make a choice. Or worse, ask on meta which one is the best