Drafting a notification for release number and updates

When new releases go live on a server, there is no way currently for users to know that this has happened. In the last release we had added the patch-notes modal to the roadmap, but it became insurmountable, so now we are looking to you for help with figuring out this feature.


I would like a discussion which focuses on two aspects.

  1. A bare minimum and easiest to implement version of the feature. Like pulls in "This server now runs v. x.y.z you can read more about it here [link to github].
  2. And one “down the line” more advanced, version of the feature where we would also work with translator teams for.

A possible solution which I discussed lightly with Gargron is what info can we pull from the GitHub, and compare version numbers, alternatively what info can we pull in with the update of a release to the server (so it does not have to connect with github again) and create a file which we can serve with the information required.
Since I am not familiar enough with GitHub, I would really need some more expert advice on this.

If we can come up with some simple ways of doing this, we may be able to make an issue which we attach to the 1.5 release. (I can dream!)

github has an extensive API, one can read release notes (https://api.github.com/repos/tootsuite/mastodon/releases/6527264 gives you access to the handwritten release notes in the body attribute), or even better


gives a list of issues closed in the milestone (we would need to start using milestones again).

What is always difficult is how to add additional information to the release committed to the git repository.

Some people add it as an out-of-band information (in the distribution zip file or on the release notes page), some people try to commit it into the repo before tagging the release, but this generates lots of trouble (conflicts on release notes).

Fetching that information by the instance software from Github would require that the application “knows” which version it is (which usually means adding git as a runtime requirement).

As far as this goes, my guess is that it knows, as the about/more page gets updated with a version number. “VERSION 1.4.1”

Just checked - mastodon/version.rb at master · tootsuite/mastodon · GitHub is manually updated on every version bump, so fetching a text of release notes should be easy.

1 Like

So what we’re looking at right now would be:

I think we’re stepping away from @hoodie’s original suggestion a bit. That said:

I think we need a more general architecture for site-wide announcements. For example, when I make a change on Elekk, I post from my account there with a “SITE NEWS” CW; that’s not helpful to anyone who doesn’t follow me.

What I’d like to see is architecture that fulfills the following expectations:

  • Allows administrators to add news on a per-site basis. (Mastodon.social will not have the same alerts that Elekk.xyz has, for instance.)
  • Displays any unread news to each user of the site the next time they use the web interface.
    • Exposes the news to the API, for use by apps.
    • Once a user marks the news as read, they don’t see the news again automatically.
  • Allows users to read through past news articles, possibly via a link on about/more.

In particular, I have suggestions for implementation:

  • Create a new table in the Mastodon database for news posts. It contains the following fields:
    • ID (numeric, auto-incrementing)
    • Date (date, set on creation of the article)
    • Text (bigtext or blob, to allow for text of arbitrary length)
  • Create a new field in the Mastodon database’s users table:
    • last_annc (numeric, the ID of the last post the user has seen)

The news posts should exhibit these behaviors:

  • Checks, each time the user loads the page, to see if the latest ID in the news_posts table is larger than the value of users.last_annc.
  • If it is, display a modal (“pop-over”) window containing the OLDEST article the user hasn’t seen.
  • Allow the user to page backward and forward through the news posts from FIRST-UNSEEN to LAST-UNSEEN.
  • Allow the user to click a “Mark All Read” button to remove the modal window. This updates users.last_annc to the ID of the most recent article.

This allows not only for announcements on new Mastodon versions - the Mastodon project can provide a template but should not include the content of news articles in new versions - but also for other site news, such as scheduled maintenance, domain blocks, site events, etc.



This is actually pretty good. Maybe those announcement should be normal toots? To avoid additional dialogs / UI elements

The issue is that if they’re normal toots, it’s entirely possible, especially on larger instances, that users will miss them. A modal dialog ensures that the information is at least displayed to each user who logs into the website.

1 Like

Maybe sticky toots on top of the, say, home timeline? Harder to miss, still integrating nicely with the UI. Dialogs are invasive interruptions.

Or maybe they could display in the Getting Started tab upon login.


I would prefer this over a modal, particularly if we ever come to some sort of implementation of groups - it would be handy to be able to expose the same “sticky toot” functionality to group owners/group moderators (assuming those concepts ended up being included in the groups implementation).

1 Like

Coming from community that started using “sticky messages on top” very often for various purposes - they became almost as bad as advertisements…

For the new version I’d rather have a nice arrows pointing to a new features on the UI itself :slight_smile: