We’ve been running this discourse site for several years now with no significant problems. Perhaps every month I’ll get an email something like this:
Hooray, a new version of Discourse is available!
Your version: 3.2.0.beta4-dev
New version: 3.2.0.beta4
- Upgrade using our easy one-click browser upgrade
- See what’s new in the release notes or view the raw GitHub changelog
- Visit meta.discourse.org for news, discussion, and support for Discourse
I was curious why Discourse always wants me to run “beta” or worse yet, “beta-dev” software. The following threads shed some light:
Some quotes:
Our nomenclature is a bit different than other software companies, but what it means when we release a beta is we’re releasing a new incremental version. We’ve said, “That’s enough changes for now. Let’s notify sites about new updates.”
So for us, a beta is a minor version bump, and a version is a major version bump. They’re checkpoints we give ourselves to celebrate the work we’ve done. We tend to release two major versions a year, but it all depends on feature development and the like. We’re not really into fake deadlines.
Regarding the branches
Stable/beta are not necessarily any more “stable” than tests-passed. It’s more the idea that the bugs are known. With tests-passed there may be new bugs introduced then fixed a few commits later.
Tests-passed is not much different than most other software releases out there, which usually release small changes every two weeks. We commit new changes almost daily instead, and they’re available via tests-passed.
We run tests-passed in production on our hosting. It’s 100% meant for production sites.
So for Discourse, their definition of “production ready” is “tests pass.” Stable release numbers are largely irrelevant anymore. This is the “new” best practice in software development but requires some investment in testing and thinking a little differently.
Ask yourself the question, if your tests pass, are you confident enough to deploy it to production without any manual fiddling or second-guessing? If not, then perhaps a little more work in testing is in order. If something breaks, write a test that detects it so it will not happen again, and move on. This is the way to move fast.
