I don't understand the discourse versioning model

(Jason Malcolm) #1

I am a discourse newb and I’m trying to get a version up and running.

I want to control the exact version which is being run, so I don’t want to just pull “master” every time I install somewhere or another dev on my team installs.

In github, I see there are different branches with names like “stable” and “1.3.2” and “beta”, but then there are tags that are “1.4.5”, “1.5.0beta”, etc.

If I want to start with a uniform environment on my team, what version is the current stable, non beta version? Should I just grab tag “1.4.5” or the “stable” branch?

Additionally: When I look at the “/admin/upgrade” for my current install, I see “discourse (e953c1c)”, which I assume is the last checkin hash from git?

(Rafael dos Santos Silva) #2

Use the latest tagged beta (1.5.0.beta10 today).

You team can all point to this tag and get the same version.

(Sander Datema) #3

In your app.yml set version: tests-passed under params: and you’ll get the latest stable version.

(cpradio) #4

No, you’ll get the latest version that successfully passed the tests. stable is a completely different branch is gets updated every 6 months to a year (except for security updates)?

beta is updated weekly, and tests-passed is updated every commit, provided that commit successfully completes all tests.

(Jason Malcolm) #5


Thanks, that’s what I was looking for. I don’t really want the ‘latest stable version’, I want to centralize on “A” version so that some peoples machines work uniformly. We can change the agreed upon version, but just have a “non-moving” target.

(Sander Datema) #6

Your’re right, my bad.

(Stefano Costa) #7

I don’t understand why focusing on a specific version will help users (if that’s what you meant) having a uniform experience with Discourse. Once it’s installed and running on your server, that should be enough for users, no? Pardon my naivety.