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

(Erlend Sogge Heggen) #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.

Add the Discourse meaning of beta to the install doc
Enable updates only to a given release
(Jeff Atwood) #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”.

(Dave McClure) #3

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

(Erlend Sogge Heggen) #4

(Dave McClure) #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?

(Stephanie Daugherty) #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).