Actually the primary impact of this is that it becomes slower to make fixes and enhancements available to older discourse versions. It’s really not common for plugins to be rendered incompatible by Discourse updates.
It is most likely not, all it does is install the OS, create
/var/discourse directory, check out given commit of
discourse_docker and fills in
Does it carry out all the same pre-flight checks as discourse-setup? Does it create swap?
If you sidestep the tools which validate the environment as a part of the product install, it’s harder to point a finger at the product itself.
It does not do pre-flight checks, not create swap. But if system runs out of memory or Docker is too old, those things are obvious, and I don’t blame Discourse for this.
discourse-setup would not save me from plugins being incompatible.
Anyway, I’m not attacking Discourse developers. You guys are doing a great job, I’m just trying to suggest some changes to the development process that would make operations people lives easier.
Thanks for the feedback @spajus. It’s always good if we can find specific tasks to improve the experience for users and administrators. Generalising things in one large topic makes it difficult to turn them into actionable tasks.
Looking specifically at your second bullet point. We aim for discourse_docker to be compatible with the latest
stable. Are you seeing something different?
As far as I know, this should be resolved and is no longer being investigated. If it’s still broken, let us know. The
sed fix is a bad idea, as it will probably break more things in future.
If chef is only provisioning an OS, and you are using
discourse_docker, then it does seem unlikely that chef is causing the issues.
@david one very specific suggestion was to tag
discourse_docker and plugins when new
discourse stable is released, so there would be way to tell which
discourse_docker commit is compatible with older version of
discourse, should someone want to set it up instead of the lastest (i.e. for restoring an older backup, or to test an upgrade procedure).
mini_racer issue is solved in latest
discourse_docker and latest
UPDATE: I cannot post again for 1 day due to new user restrictions, so read the updated post to see why not everyone would always want to install latest discourse.
I guess I’m trying to work out what you would use the tags for? If discourse_docker always works with the latest stable, you can always use the master branch of discourse_docker…
That topic doesn’t cite a specific fix or commit, if it has been resolved it would be good to see something to the affirtmative in that sense. More than happy to nuke the sed fix if so.
Sure, I added the github link to @Falco’s post in the other topic. Here is is: FIX: We need a newer mini_racer for ruby 2.6.3 · discourse/discourse@99dd426 · GitHub
Well, there is a reason we:
- don’t default anyone to stable
- don’t recommend anyone to run stable
We run thousands of instances of Discourse. And since we deploy from tests-passed we have lots of testing on that.
When you actively go away from the standard we suggest, it’s going to be less tested. Even then we issued a whole new release to fix the issue in the same day we got a good report.
I would personally agree with the idea of tagging
discourse_docker with the same version as the stable release. We currently use Puppet to automate the process of bootstrapping new Docker containers, which we pin to a specific stable release of Docker (we’re in the kind of corporate environment where the idea of running “beta” software is basically a no-go). It’d be nice if I could use that same version number as a tag in the
discourse_docker repo and know that the version of the launcher I’m using is going to be able to build the version of Discourse I want to build.
Just a note that the people who maintain the software claim that the
beta branch is more reliable than
Quite, we live in an age where governments practice agile principles and rapidly release software under beta to their citizens.
Here’s an idea, let’s drop the ‘b’ from stable
I always felt farming or gardening was the best metaphor for actual software development because it is a living thing. You’re growing things and that takes regular upkeep. Get busy growin’ or get busy dyin’
stable stale is the equivalent of a fallow field?
I get it now, but your “beta” releases being more stable than non-beta is really a confusing mixed message for the rest of the world. I get it, you are developing an in-house product, which you have interest to keep growing and up to date at all times, and you are giving it away for free to everyone, but then it seems there are two choices:
tests-passedand keep updating it every couple of days, and help you fix all the the bugs and issues
- Let you host it for us
Surely both scenarios are win-win for Discourse as a company. I can’t blame you for that
But really, you should then just remove all non-beta tags, unless you want it to be “open source with a catch”.
Running Tests-passed and upgrading when there is a beta or a specific problem is what most people do. That’s a couple of three times a year.
If you’re in a corporate environment with uptime/stability expectations, then you should run a staging server.
Next time I’ll try to do just that (will use
test-passed). It’s much more clear now after you explained it.
Yeah, I’m with Tomas.