3.2.1 is not a "clean" version commit

I know you recommend tests-passed, but I need to follow the stable branch, and 3.2.1 just showed up. However I wonder why does it show up as 3.2.1 +9. Isnt the stable branch supposed to be on the released tag (at least directly after release)?

And also, why does it show 2 versions, which one will it update to. And whats the commit id I will get? It would compare Comparing e049f82681b0f719f740cb378564f03711ff1c08…6a0aa03aa285306560af679c84903be0d58a4203 · discourse/discourse (github.com) - is that expected? The e040f.. is my current hash according to the dashboard.

The dashboard start page doesnt show the new version yet, however:


In my understanding, v3.2.0 +9 +9 means a few commits are available on top of your current version (before 3.2.1)

v3.2.1 +5 would mean you can update to the next version, 3.2.1, and a few commits have already been added on top of this version. Usually, I believe that would be important fixes backported from the main branch.

I understand that could be confusing a first. I’m wondering if this could be improved. :thinking:


ah ok, so the repository column means “your local current install” - that could make sense, thanks. And i read the 3.2.1 announcement today, so i was supprised that there are already more commits, but if this is expected, its also fine with me.,

Any idea why the main dashboard doent show me that update yet? (I can understand when its only refreshed daily but then it should have also updated when i checked on the “Updates” tab manually.


This is correct, the next version tag is 3.2.1. We missed a couple of commits just before the bump, so they got added right after, hence the +5. Usually we make sure to backport before the tag is issued, but we missed it this time. It happens.

Note that the +5 commits there fix the following issues:

  • a translation for guidelines_topic.body
  • an error with security key validations in an older Firefox version (not the latest)
  • styling for the video placeholders

The commit id you will get after the update is 6a0aa03 @ecki, it includes the fixes above.

The “Updates” screen is from the docker manager plugin, the main dashboard is core’s check, which only happens once a day. The two don’t communicate, hence the discrepancy. (Good point, though, it would be nice if they did communicate.)


Very helpful, thanks a lot.

While we are on the topic, is there a mechanism to decide when a rebuild should be done, for example emergency base/db/data container updates or is that never signalled in frontend update dashboard,