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 stable.
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’
So 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:
- Use
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.
This has been discussed before, but I still support the unpopular opinion of running stable for stability.
Our site has been on the stable branch for about 3 years and 603.000 posts later the experience is mostly (95%) good. The roling branches were way too volatile with UI changes, breakage and other surprises. We are especially careful about introducing change to the UX.
Sure, after every major upgrade we often need to update our slightly customized themes, adapt to other changes and usually also report some bugs.
2.3.10(안정판)로 업그레이드한 후 문제가 발생하여 이 주제를 우연히 발견하게 되었습니다.
최근 저희 사이트에서 사용 중인 일부 플러그인이 더 최신 버전의 Discourse(예: discourse-assign)와 호환되도록 업그레이드되었습니다. 이 업그레이드가 부정적인 영향을 미친 것으로 보입니다.
플러그인 설치를 플러그인의 안정(stable) 브랜치를 참조하도록 변경해 보았습니다. 불행히도 모든 플러그인이 안정 브랜치를 제공하지는 않습니다. 이는 Discourse 생태계 내의 또 다른 비일관성입니다.
제 변경 사항이 Discourse 설치에 긍정적인 영향을 미칠지조차 확신할 수 없습니다.
네, Discourse 자체와 모든 플러그인에서 안정 브랜치를 명확히 정의하면 안정성을 높이는 데 도움이 될 것입니다. 다만 그 전에 '안정성’에 대한 명확한 정의가 선행되어야 합니다
다음과 같은 접근 방식은 선택지가 될 수 없습니다:
“소프트웨어를 유지보수하는 사람들이 beta 브랜치가 stable 브랜치보다 더 신뢰할 수 있다고 주장한다는 점에 유의하십시오.”
어떤 플러그인에서 문제가 발생하고 있나요?
최소 discourse-assign 플러그인은 필요합니다.
다음 플러그인 설치를 안정적인 플러그인 브랜치를 사용하도록 변경하면 누락된 SVG 아이콘 문제를 해결할 수 있습니다:
- git clone --branch stable GitHub - discourse/discourse-assign: Plugin for assigning users to a topic · GitHub
- git clone --branch stable GitHub - discourse/discourse-solved: Allow accepted answers on topics · GitHub
- git clone --branch stable GitHub - discourse/discourse-canned-replies: Adds a means to insert templates from the composer. · GitHub
이 항목에 대한 작은 업데이트입니다 - 저희 official 플러그인과 테마 컴포넌트에 호환성 파일이 추가된 것 같습니다. 
예시: