Please don't pressure self-installers to be on Beta branch

community
1

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 place to be if you want the least amount of surprises, which is ideal if you have very limited resources dedicated to maintenance. As long as Discourse has a Stable branch, that’s what we’ll be using.

If supporting the Stable channel is a problem for you, it shouldn’t exist as an option.

5 Likes
2

That’s what our customers are on.

You are free to choose what’s right for you, but we recommend that people follow the betas unless they are extremely risk averse.

To be honest, there are quite a few bugs in stable releases, bugs that you’ll labor under for months. You may or may not care about that – the tradeoff is “devil you know”.

2 Likes
3

Perhaps just drop the ‘b’ and call it ‘stale’? :wink:

5 Likes
4
2 Likes
5

OK, on a less trolling note…

I think what @erlend_sh is describing is a notion of the stable releases being the best “community synchronization” points.

But maybe the cadence of these sync points is what needs to change.

Perhaps a more regular cadence can be found to better balance these two goals:

  1. keep people closer to ‘latest’
  2. give plugin devs and translators time to ‘sync up’

Regardless of what you call that, what would be the best cadence for “community synchronization” with the above goals?

4 Likes
6

This seems like more an issue of documentation and positioning. It’s not clear from the installation document that beta is actually the recommended branch for production sites, the branches aren’t listed in the sample app.yml and the term “beta” screams “unnecessary risk” to those not familiar with the Discourse development model and neglected state of the stable branch.

Adding explanatory language to the install document and the sample app.yml would go a long ways to solve this I think. From a positioning standpoint, it might be worth having a new branch that’s named so as not to scare off the risk averse and the suits as easily (many companies have policies discouraging or prohibiting “beta” software in production).

2 Likes
7

As a long time Microsoft beta tester, I’ve come to understand Discourse development terms are incredibly conservative. In Microsoft vernacular, Discourse’s tests-passed would be analogous to RC, Beta to RTM, and Release to LTSB. And yet, even those comparisons are reaching in Microsoft’s favor since I cannot ever recall a broken Discourse Beta yet but I heard numerous reports of issues with, for example, Windows 10 Fall Update 2018’s RTM release.

10 Likes