I noticed that every now and then my Discourse site send me an email telling that a new version is available to install, but every time the version is “x.y.z.beta something”, so I’d like to know: is Discourse always some “beta” version? Is it good to install in a production environment (i.e. to serve hundreds, maybe thowsands people)? Or does this concerns only free and not “cloud” versions?
There’s a good explanation of the branches we use here:
So Discourse is in a perpetual beta state, meaning that we’re always working on new features and refinement. In our case beta does not mean unstable; we host sites with millions of monthly pageviews on our tests-passed and beta versions.
To add to what @awesomerobot posted:
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.
I’m on this thread because of the same reason.
Why don’t the install instructions tell us to install the stable branch?
How can I change to the stable branch or is it too late since I’m on a “higher version”
Can the instructions be updated?
If it is too late, how do I stay on the stable branch once it is updated?
Do I need to keep incrementally updating until I get there?
You can’t swap to stable until it catches up. Discourse doesn’t support downgrades.
A better question is: why would you want to?
Stable isn’t as widely used, the focus for development is on tests-passed.
Assuming you aren’t blindly upgrading a production site, and are testing each upgrade prior to deployment, the most feature-rich and well supported release is going to be the default.
Sorry, this must be somekind language barrier matter-issue, but does the focus mean
- development of Discourse itself and how branches are build
- everybody else is doing mostly development of Discourse
First one means that production sites that have focus on functional and stable forum should use test-passed.
Second one means a production site, that products forum, not coding, should use stable.
Yes. I desperate need some english lessons because these nuances aren’t totally clear for me.
But when the first guess is right, why there is stable-branch if it is not ment to be used?
We run tests-passed
in production on our hosting. It’s 100% meant for production sites.
Stable means all the software bugs are known. You won’t be getting anything new (including new bugs, but also bug fixes) until the next stable version is released. It’s simply site preference – want features as they come? Use tests-passed. Want an absolutely stable build that won’t change except in major version updates? Use stable.
To that I’d add “want to wait 6 to 8 months for something that is a bug but not deemed a security risk to be fixed?” Use stable
.
That’s not entirely true. There are many bugfixes backported to stable.
Well, that’s quite true I’m sure.
But hypebole is the best thing ever!
True, the showstopper ones. Smaller bugs are not.
It would be good if there were a choice in the general instructions, sort of like LibreOffice download choices or Debian.
I am hosting the site on DO but my co-owner was originally from discoursehosting.net as a subdomain, and he sees all of this maintenance and say “Why don’t we just use discourse hosting?”
I told him that we have our own name, server, higher tier plugins (like emoji likes and google sign in), and other things. I told him that he was probably using older discourse and never updated either.
I too would rather just use stable and forget about it until 6 months later. I’m a daily driver of Ubuntu, but I get a little nervous typing in those few build commands. Plus the server goes down for 5 minutes when I rebuild.
On the other hand, I’m going to request a backup feature to be integrated and would jump on beta for it
Just to avoid any kind of speculation: at Communiteq (formerly discoursehosting.net) you get your own hostname, plugins of your choice on the Professional plan and up, and we backup and update your forum for you. So yes, most of your problems will indeed be solved by using managed hosting.
The original issue was to request provide a stable build option in the github install instructions. I see that you provide stable releases for your customers. Perhaps you can kindly explain how to clone and install a stable release? That was also my original question.
As a small and semi-private group, there is no justification for anything less than the DO $5 server. However, you have a great service for $40 per month for the professional plan or the basic plan. I wish you the best of luck. It is a good deal compared to the official discourse plans. All options are great for those who can afford this. That is the great part of FOSS.
I believed the decision to install on tests-passed by default is quite intentional.
It’s far easier to support new installations at a single software level. As the support provided here is community-based and for the most part 100% free there’s no good reason to complicate it.
The standard install instructions are simplified for a reason.
Running stable
is considered an advanced setup, so you need to edit the app.yml
by hand. You can search for “version” and see documented there what to do.
Modifying discourse-setup to include this as an option would be confusing to most people, so I don’t think it’ll be added there.
Maybe a helpful metaphor is that the “stable” branch is like the disc based Microsoft Office, whereas the “tests-passed” branch is like the cloud based Office 365. Both are viable options, and both get updates eventually, but for a product that’s fundamentally online already and which has a small support team, it’s more productive to be able to instruct people to update their installations to the current code, so that bugs can be tested and fixed promptly. As a forum admin it’s great to be able to report a bug and update to a version that fixes it within a few days, sometimes even the next day. I haven’t used any other web apps that are as responsive as that. (Not that every bug is fixed instantly, but many are.)
@pfaffman, I followed the link and the one it led to, but saw nothing about setting the config to stable
. What am I missing? Do you mean 'search the app.yml
file for “version” '?
but I don’t think you can go from test-passed
to stable
(as you would go back in commit and probably need to reverse some migrations in the database, unless your test-passed
version is old enough to be over-passed by the newest stable I suppose )
Thanks for the speedy reply!
I was expecting that the updating would just suspend until the next stable
release cycle.
Any insight on this? Why would anything immediately change from flipping the #version
switch?