Enable updates only to a given release

Beta has zero quality guarantees. It’s just a literal point in time where we cut things off.

In software, you want to be on latest.

1 Like

Well, sure I do. :slight_smile:

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.

Hasn’t for four years, so I don’t think that day will be coming any time soon, if past history is our guide.

1 Like

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.

1 Like

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.

1 Like

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.

There are bugs and regressions in literally every release.

1 Like

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

A post was split to a new topic: Update log to track updates to Discourse

I think it’s pretty funny that we’re now arguing about going from tests-passed to beta, since back in the day the argument was about going from beta to stable :joy:

I guess that changed at some point.

I’m still on the self-hoster’s side of the argument, but Discourse as a project is clearly in a tough predicament on this one.

In the WordPress community, self-hosters default to stable while wordpress.com is on the equivalent of tests-passed. There’s no doubt this has been a huge contributor to WP’s developer ecosystem, since developers can take aim at a stable target for about 3-5 months at a time. Say what you will about WP’s wild assortment of plugins; the level of developer engagement they have is unprecedented.

The price they pay for this is all the work that backporting security fixes entails. I’m not sure how much work it would take to backport only critical security releases to the Discourse stable branch, but I’m sure it’s not trivial. We need to get bigger before we can feasibly absorb that cost on behalf of the community.

PHP is the main reason for that, though.

There are literally hundreds of PHP CMSes, blogs and forums around, but only one WordPress. PHP is just one of many, many things they did right to grow their developer ecosystem, and I certainly think it’s fair to say that a stable release channel has been a major contributing factor.

It’s also quite a bit older, considering WordPress 1.0 was in 2004. Today in “WordPress years” would be… 2008. That’s almost ten years ago.

The other thing that’s not mentioned is that so-called wordpress “plugins” are basically raw PHP code that makes low-level PHP calls and directly touches the database. It’s not so much an API as, well, “add random crap to the codebase”.

An API would require a stable interface between the app and the plugin; that’s not how WordPress “plugins” work. They’re just whatever PHP you want to enter, and whatever you want to do to the database.

Here is a fun list of wordpress “plugin” vulnerabilities to read through at your leisure… WordPress Plugin Vulnerabilities … if you have even one of these installed, it is game over for you.


Totally agree with this principle. I’ve used Discourse for six months, updated on nearly a daily basis and never seen a serious problem (data loss / corruption / downtime) in all that time.

However, there are, of course, trade-offs. Because of this upgrade style I made the conscious decision to use only official plugins.

I had a few problems at the beginning with unofficial plugins (e.g. Topic List Previews) breaking when I upgraded Discourse.

Some may argue for more plugins to be promoted to official status so (I assume) they are continuously integrated and their automated tests are run in CI alongside Discourse core.

But I think there would be an agility cost of doing this, and I think the current setup is a great choice of trade-offs. Props to @codinghorror, @sam and @eviltrout for achieving this.


One argument for defaulting to beta is that switching to test-passed is simple, while the switch back usually requires waiting (and risks strange problems if the wait isn’t respected).

Maybe the discourse-setup script should ask the user which branch to install?

Well, having thought some more about it, I’m pretty convinced that for my customers tests-passed is probably the right choice. People who pay me to create a droplet, configure mailgun, and set up discourse for them, don’t have plugins installed and are mostly running small-scale sites can afford a day or two of downtime a year in the fairly unlikely event that occurs. People who are likely to get in trouble with tests-passed are those who have non-official plugins installed and are more likely to have resources, technical or fiscal, available to deal with problems as they arise.

That said, I’m about to submit a PR for ./discourse-setup that allows people to re-run it to tweak settings, so I could add the ability to choose the branch. What say ye, @codinghorror?

1 Like

I violently disagree; after two years of setting up at least 100 325 of these $99 install sites, they were all on tests-passed and I can recall only one or two times a bug serious enough to warrant a rebuild went out. I looked up some stats from the Mandrill switchover. Note that this was as of March 2016:

  • roughly 325 self-supported $99 Discourse installs have been performed based on the standard email title string we use for all handovers.

  • about 115 of those installs are still alive, because that’s how many emails about Mandrill closing down I sent.

  • I’d estimate maybe half of those or 55 were meaningfully alive, that is they had some real activity, and were used somewhat actively by a community of some sort

That said, now they are your customers so you should absolutely do what is right for you.



Well, having thought some more about it, I’m pretty convinced that for my customers tests-passed is probably the right choice.

So we agree. :slight_smile:

Just be aware we have major security vulnerability fixes on a regular basis. So people who don’t update can have really bad things happen to their servers.

We just fixed a serious DDoS issue today, for example, with onebox…