Unless I misunderstand how upgrades work, when you do an upgrade from the web interface, you get all of the commits from the branch that you’re on. It would seem preferable to be able to get just the commits from the most recent release (e.g., Discourse 1.8.0.beta2). Right now saying that you’re on “Discourse 1.8.0.beta2” means little, because depending on when you upgraded you could have one of a hundred different commits.
If one could upgrade to the commit of the most recent release, then one could have increased reliability by watching meta for a few days after a release before upgrading.
Better still would be a way to select releases from the web interface and be able to downgrade, or run a couple releases behind the bleeding edge.
If you are on tests-passed, that is true… But I thought if you were on beta, it would only get up to the last tagged beta release latest commit in the beta branch, which only gets updated when a new beta is tagged or a security fix is back-ported.
Actually, I need to fix my prior statement, it will still get all latest commits on the beta branch, it is just the beta branch only gets updated when a new beta is tagged/released or security patches are back-ported.
Where as tests-passed is updated as soon as the CI build completes and passes (hence why you could literally update Discourse daily when on tests-passed).
As for a sane default. /shrug. I have no strong opinions on the matter, but Discourse choose tests-passed for a reason, likely to ensure users are up-to-date for security fixes and features. But I leave that to them. It is simple enough for others to change it to fit their own desire.
Well, not for the bulk of the people that are my customers. For people who can’t follow the standard install instructions aren’t likely to have any idea that this behavior could be changed, and if they did, changing it is not quite simple.
Do I understand correctly that if you’re on tests-passed then a Norma Person has little way of knowing what code they’re running? That is, the version number you get from view/source doesn’t really tell you what you’ve got, and you’ve got to look at the Git ID? E.g., Meta and my site are both on 1.8.0.beta2, but they’re running different code:
Discourse 1.8.0.beta2 - https://github.com/discourse/discourse version e7564dc1d74aaa0477a3c488d063dd9d98443784
Discourse 1.8.0.beta2 - https://github.com/discourse/discourse version 521ced38c5c8a78c5c95f65a53b1d7c76c842bed
I guess my question is, can you tell me a little more why tests-passed is better for a Normal Person than beta?
No – you can see on the dashboard what beta you are on with a +number in front of it. That plus number is the number of commits past the beta you are on. Betas are released every 2 weeks, roughly, sometimes a bit more, sometimes a bit less, so this tells you a broad vintage of the code in time.
You can always view source in your browser to see what exact commit you are on, this has been true since Discourse 1.0.
<meta name="generator" content="Discourse 1.8.0.beta2 - https://github.com/discourse/discourse version 1a45fe94a284d7809abc9a64f371e58b80ec50f8">
Can you tell me a little more what the actual problem is? Having everyone on latest hasn’t been a significant problem in four years of the project, so I’d love to hear what your actual problem is.
There are rare cases where new bugs go out with each commit, but they’re not common, and rarely serious. And 99.9% of the time the fix is “rebuild to get very latest”.
Aha. It is easy for a normal person to see what commit they’re on.
I still don’t quite understand how tests-passed rather than beta is the best branch for more people. Beta seems close enough to the bleeding edge (usually a week or two)
My argument is that by running on beta one can wait a couple days after the release, let the brave-hearted do the upgrade and see if there were any regressions before taking the plunge.
At some point it’ll make sense for not everyone to be on the bleeding edge, though maybe the time isn’t now.
When I started running Linux, I didn’t mind downloading all new binaries for every new kernel release. I switched to Ubuntu because it made upgrades easier and safer. For a long while after that, I’d upgrade to each new Ubuntu release as soon as it came out, or even use the pre-releases. Now, I’m more inclined to stick to an Ubuntu LTS and while I might run 16.10 on my laptop, I might not upgrade it to 17.04 the week it comes out.
That’s a 25 year timeline. So that’s a past history that makes me think otherwise, that sometime soon people will want to stay a bit behind the bleeding edge. Whether “soon” is 2 months, 2 years, or 20 years, well, I guess we’ll just have to wait and see.
To be honest, there are a few that do that now. Sitepoint (SP) would be a very prime example of it. They don’t run on “latest” persay, SP has their own fork of Discourse (for many reasons – typical corporate reasons) that gets updated when their ready to pull in the recent changes (every 3-4 months?) and SP will cherry pick security fixes to deploy those immediately.
It gives SP the stability they are comfortable with but at the same time they are left secure as they cherry pick the security updates into the fork.
I will say, this is a very complicated setup. You must be 100% comfortable with Discourse internals, GitHub - maintaining a fork, and be willing to spend a lot of time merging from said fork every time you want to update. It isn’t for the average person.
However, updating your customers app.yml to beta before handing it over to them, isn’t a horrible idea, and if it gives them piece of mind (or a breather from the feeling of “OMG! Another Upgrade already”), awesome! And that is much cleaner and easier to manage than the fork approach.
It is much more important to understand that software needs regular updates, and have an update process that is smooth, seamless, and works – ideally completely automatically. Optimize for the update process, not “gee, I guess if I hang back on {ancient version X} I won’t have any problems!”
I’m still waiting to hear what your actual problem was, @pfaffman.
The actual problem is that sometimes there are regressions, and though they’re somewhat rare, but they happen. Being able to stay a couple weeks behind the bleeding edge seems like it’d have considerable appeal for lots of folks.
I’d like to find a release where the Babble chat plugin and Sidebar plugin worked and freeze there for 3-6 months.
I daren’t install any plugins except the official ones as they break all the time.
1 Like
erlend_sh
(Erlend Sogge Heggen)
Split this topic
20
