Updating on the beta-channel still gives +-versions

Looking at this explanation, I think something is wrong with my installation. My config file specifies version: beta since a long time, and I have applied many updates since. However, I’ve almost always been on a version with a non-zero number of additional commits. For example, currently, I’m on v1.4.0.beta9 +88.

Am I misunderstanding the explanation, is the version display broken, or am I actually still running tests-passed?

The reason is that the version is updated in a merge commit, and this is where the beta branch points, but that is not where the tag is. So that branch historically includes a bunch of stuff not in the actual tagged commit.

jb@syno:~/tmp/discourse (beta) $ git gl
*   fbd5325 (HEAD, origin/beta, beta) Version bump
| * 766903c (tag: v1.4.0.beta9) Version bump to v1.4.0.beta9
| * 8ea765f Update Translations
| * 0442457 Fix deprecations in admin groups interface
| * a8d20c6 FIX: eyeline was broken in dev
| * 930d066 correct logster rendering issues
| * 94a130a FIX: widen distributed mutex to avoid race condition

Why is the tag not on the merge commit in question? No idea. I’d consider it broken… Anyway, it means you get the +88 from git describe:

jb@syno:~/tmp/discourse (beta) $ git describe

That was my point to @codinghorror, I assumed it was widely known and possibly now intended that when we’re prompted to upgrade beta the process takes us to whatever the ‘current’ level was, rather than the last tagged beta build.

If not then I have to ask how long it has been broken for, we’ve been running Discourse for 9 months at least and always observed that behaviour.

Wait, what you’re describing seems to be what’s happening when you’re on tests-passed:

  1. When you upgrade, you get the latest tests-passed version.
  2. You can manually upgrade whenever tests-passed has advanced.
  3. You are only notified to upgrade if the version number changed.

You can argue that it’s troublesome that notification-wise, it feels like you’re upgrading to a beta, while in fact you’re upgrading to the latest commit – but that’s what your app.yml specifies.

When you explicitly selected beta, the behavior seems to be, as explained by @calmh:

  1. When you upgrade, you get the latest beta version.
  2. You can only manually upgrade when beta has advanced (which apparently means either a new version or a manually merged security-related change).
  3. You are only notified to upgrade if the version number changed.

This seems fine to me, except for the display issue this topic is about. (Although you could argue that you should be notified of pending security updates…)

I’ve just checked and we are, we didn’t alter the setting, the config.yml defaults to it:

## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

Presumably that value just needs switching to beta to get the behaviour we expected, isn’t it a tad risky to have users default to this setting and not mention it in the DO setup guide?

1 Like

No, it takes you to the right release. But the way they’ve tagged it makes git describe show something other than you expect. In short, you’ll always see the correct beta version tag plus a random increasing amount of commits, even when you’re “on” the beta release.

It’s a cosmetic issue because they’re tagging one release and pointing the beta branch at another one.

See my “graph” above: beta points to fbd5325, but the tag is on 766903c.


@neil we should clean this up for next beta if possible.