Hello
My discourse site is running version v2.2.0.beta5 +24 and I want to get it onto the non-beta of 2.3. Though the upgrade panel on my site looks like it’s trying to grab the 2.4 beta. Is there a way to retarget the update at 2.3 release? Maybe I need directions to do this in Docker instead of the admin panel?
Thanks
tests-passed (latest beta) is the default version for all installs. Migrating to stable takes some doing in your container config yml on the server you’re running. If you’re up to the task, there is a line like the following:
https://github.com/discourse/discourse_docker/blob/master/samples/standalone.yml#L37
You’ll need to uncomment that (delete the #), change “tests-passed” to “stable” and rebuild.
It’s generally not recommended that you run on “stable” in spite of its name.
It probably won’t hurt, at least for a while, to be on Stable, but it’s likely to cause problems.
Ah if you advise against it then I will heed that advice. We’re not a feature-needy group, a bunch of cyclists operate our team communications in Discourse. We’re happy to sit tight locked on our version for now but I was assuming that 2.3 was “stable” and potentially a better place for us to lock to as opposed to an old beta build.
It’s stable indeed, just as stable as the version 2.2 where you’re in. The issue is that if there’s any security update, you won’t get it as expedited as possible. That’s really most of the issue.
Discourse handles something like: master -> test-pased -> stable. Being test-pased the most stable and updated version of Discourse (that’s why it’s the default option).
It’s your choice to go to 2.4 (test-pased) or stay at 2.3 (stable).
That’s pretty close @marianord. Just add beta between tests-passed and stable and you’ve got it. I would add that I wouldn’t necessarily agree that tests-passed is the most stable - Discourse is a fast moving piece of software, there’ll always be bugs - I’d say any bugs on it get fixed pretty quickly, and you can update to the latest tests-passed release any time to pull in the fixes.
@Json_Blob, stable is “stable” in the sense that it does not get updated very frequently. While we do our best to iron out bugs before each of our major releases, we can’t guarantee we’ve found all of them. So stable means that any bugs you have will be there until the next major release, but you can also trust that new bugs will not be introduced for many months. See the second half of my post below for more details on each of our branches.
That makes more sense, ok, so it sounds like the advised path forward if my group decides to take an update is to get onto the “tests-passed” branch and off beta. Is that summation correct? In which case I follow Jeff’s instructions above for the YML adjustment
You’re already in the test-passed branch, as it’s the default one when installing. But your version will keep looking something like v2.4.0.beta1
OH ok i was unclear then, I thought since my build had “beta” in the version I was on the beta branch. Got you.
That’s incorrect, the team does a great job in cherry picking all security issues into stable.
Even if there’s a new security update between versions? As it happened between 2.2 and 2.3?
Correct. Any major security fix (those labeled SECURITY: on GitHub) are backported to both beta and stable. On occasion, though very rarely, we’ll also backport a non-security fix if we deem it critical enough.
Just keep in mind that in some cases the stable branch might stop working with the discourse-docker repository.
The good news is that from what I see in these cases, the discourse team backports the changes to the stable branch for it to work again.
I think that creating tags and branches in the discourse-docker repository would help a lot to avoid these kind of problems. This is up to the discourse team, tough (or you can fork the repo).