# Enable updates only to a given release

**URL:** https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277
**Category:** UX
**Created:** [24 يناير 2017، 4:41م UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277 "2017-01-24T16:41:38Z")
**Posts on this page:** 10
**Page:** 2

<div class="post-metadata">

### Author: ![erlend\_sh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/erlend_sh/32/119475_2.png) [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [25 يناير 2017، 11:00ص UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/21 "2017-01-25T11:00:54Z")

</div>

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` 😂

> [@Please don't pressure self-installers to be on Beta branch](https://meta.discourse.org/t/please-dont-pressure-self-installers-to-be-on-beta-branch/32237):
>
> I’ve heard this a couple times now, and understand where you’re coming from, but being on Beta is not doable for us. We have no dedicated sysadmin or web developer who can attend to the plethora of smaller things that can pop up on the Beta branch: Theme-breaking updates UX changes that we’d like reverted Plugin incompatibilities I also like knowing what’s coming. It allows me to tease new features to our users, and plan new workflows. Every tech-savvy person knows that “Stable” is the plac…

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](http://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](https://make.wordpress.org/core/handbook/about/release-cycle/releasing-minor-versions/) 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.

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [25 يناير 2017، 11:34ص UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/22 "2017-01-25T11:34:19Z")

</div>

> [@erlend\_sh](#):
>
> Say what you will about WP’s wild assortment of plugins; the level of developer engagement they have is unprecedented.

PHP is the main reason for that, though.

---

<div class="post-metadata">

### Author: ![erlend\_sh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/erlend_sh/32/119475_2.png) [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [25 يناير 2017، 11:38ص UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/23 "2017-01-25T11:38:02Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [25 يناير 2017، 11:50ص UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/24 "2017-01-25T11:50:30Z")

</div>

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 | WPScan](https://wpvulndb.com/plugins) .. if you have even one of these installed, it is game over for you.

---

<div class="post-metadata">

### Author: ![ChrisBeach](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chrisbeach/32/214628_2.png) [@ChrisBeach](https://meta.discourse.org/u/ChrisBeach)
#### Post date: [25 يناير 2017، 12:07م UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/25 "2017-01-25T12:07:54Z")

</div>

> [@codinghorror](#):
>
> Optimize for the update process, not “gee, I guess if I hang back on {ancient version X} I won’t have any problems!”

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.

---

<div class="post-metadata">

### Author: ![fefrei](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/fefrei/32/119538_2.png) [@fefrei](https://meta.discourse.org/u/fefrei)
#### Post date: [25 يناير 2017، 3:21م UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/26 "2017-01-25T15:21:44Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [25 يناير 2017، 3:53م UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/27 "2017-01-25T15:53:15Z")

</div>

> [@fefrei](#):
>
> 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](https://www.literatecomputing.com/product/discourse-install/) 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?

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [25 يناير 2017، 8:40م UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/28 "2017-01-25T20:40:52Z")

</div>

> [@pfaffman](#):
>
> 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.

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](https://blog.discourse.org/2016/03/switching-your-discourse-from-mandrill-to-mailgun/) 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.

> [@pfaffman](#):
>
> What say ye, @codinghorror?

Nope.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [25 يناير 2017، 8:45م UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/29 "2017-01-25T20:45:14Z")

</div>

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

> [@codinghorror](#):
>
> I violently disagree;

So we agree. 🙂

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [25 يناير 2017، 8:59م UTC](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277/30 "2017-01-25T20:59:16Z")

</div>

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..

[Previous page](https://meta.discourse.org/t/enable-updates-only-to-a-given-release/56277.md?page=1)
