@joffreyjaffeux Should Discourse.redis be backported to stable and beta? I guess that would be easier than adding code for backwards compatibility to multiple plugins.
Short summary: tests-passed worked, I had a downtime of 1 day
Longer version: I think this is one of the highest quality open source software written on the internet today, with a solid business model and a great team. How come the upgrade mechanism is just so broken?
The in-app upgrade feature gave me so many downtime that I decided not to use it at all, but always do a rebuild.
But as you can see from this thread 2 out of 2 times recently the rebuild also gave a very broken app, something which I could not possibly fix on my own, other than going to “tests-passed” based on recommendations here.
Why is the upgrade mechanism so broken in such a well written software? Why is it that I have 5+ year Wordpress sites working without any problem with build-in upgrade mechanism?
What is the point of having releases in Discourse if there is literally no way to use them? A rebuild is always from a git branch and releases don’t have anything to do with git at all.
For me a release would be either a git tag or a zip file. Why can I not just use rebuild with 2.3.x, like I could do with any modern package manager today?
As it turns out, tests-passed is what discourse.org deploys on their servers and it is better tested and more reliable than stable. If you stay on tests-passed you’ll have fewer problems. If you want to run stable then you need to understand that it will require more work than running tests-passed, like running a staging server to test upgrades before you run them on production.
I just want something which is stable and reliable, and based on
tests-passed is what discourse.org deploys on their servers and it is better tested and more reliable than stable
I’ll be sticking to this. Two things are still very strange:
Why is this called test-passed and not stable then, if it’s indeed stable. “stable” could be renamed to “legacy” of some sorts.
The release system still doesn’t make sense. If we are building from a Git branch, what’s the whole point of doing releases at all? I’d love to be able to stick to 2.3.x until 2.4.x matures for example, and I believe with Discourse’s model this is not possible at all.
With all due respect but I disagree with this. Stable is very reliable and, well, stable. Rubygems updated a dependency which caused bothtests-passedandstable to break and solving this was just a matter of backporting a fix.
BTW this could have been avoided by pinning rubygems to a specific version in the gem update command. gem update --system 3.0.6 would have been safe.
The fact that stable was longer broken than tests-passed is just a coincidence and - as far as I can remember - a first.
We’ve been doing this (sticking to stable as a default) for over six years with many hundreds of Discourse instances without significant issues.
Just in this thread there are multiple occasions when stable left rebuild in a broken state, it’s definitely not a first. If discourse.org commercial instances are on test-passed then I’ll be sticking to that.
We’ve been doing this (sticking to stable as a default) for over six years with many hundreds of Discourse instances without significant issues.
Sticking to stable and sticking to 2.3.x are very different things. For example stable doesn’t allow you to stay on 2.3.x until 2.4.x matures enough. For example with all things in production, I prefer to upgrade not until x.x.3 or x.x.4 comes out. This is not possible today I believe.
I know that’s true, but you’re not the average discourse admin. You’ve saved me a bunch of times and as a rule I read everything you say twice to make sure I’m remember it, but I still think that for most normal people it’s safest to stick with tests-passed.
But even if I do, it won’t save me in situation where stable is broken, will it? In both cases the problem was a missing backport, and that’d equally be missing in any git commit id, I believe.
Hence there is no such thing as a Discourse “release” where you download a zip file a-la-Wordpress or use a package manager like yarn/pip/gem simply because the Discourse is not released, but is “rebuilt”, always using live versions of external packages.