I like Discourse a lot and I appreciate having such awesome Open Source software available for free (ignoring the cost of hosting it myself). So I hope you guys don’t think that I’m bashing the great work you’re doing with this post.
But I think there are some improvements which could be made to help users. Some of them are quite tedious and possibly annoying for developers but are quite useful for Discourse users.
I’ll make separate topics for each of the improvements I’m thinking of, this is the first one.
Discourse has a helpful message telling you that the instance is out of date and recommending to the latest version. There is an even more helpful link pointing to the changelog. And this is where things get blurry, since the link is always https://github.com/discourse/discourse/commits/master. Which is fine, since you can see the changes.
However… that’s the full list of changes. So you have to scroll quite a bit to find the things you want (such as: first commit included in v1.5.0.beta10, last commit included in v1.5.0.beta10). The commit messages format is not standardized and is also quite hard to parse at a glance.
I recommend adding some sort of tags at the start of the message, with a limited set of tags available: fix, improvement, doc, release, etc.
And a format which makes the tag stand one. Some examples I’ve seen and used in the past:
FIX - … IMPROVEMENT - … DOC - … RELEASE - …
[FIX] … [IMPROVEMENT] … [DOC] … [RELEASE] …
FIX: … IMPROVEMENT: … DOC: … RELEASE: …
Extra style points awarded if bugfixes point to issue tracker IDs ([FIX-182323] - …) or if the changelog is automatically transformed into a human readable version such as this one: Release Notes - JFrog JIRA
I’ll leave it up to @team to decide whether to delete, merge, or let this topic remain, as I do think you bring up a good point. While there is a convention in place, it isn’t used at all times by those who commit to the project, and I would agree that makes it much harder to follow when looking through the log.
Discourse is in very active development so the changelogs are going to be quite long. If you want something less granular than the resources that have already been pointed out, you might want to keep an eye on the #releases category.
It’s possible that you may have to wait until the next major point release before you can switch to stable. If you’re beta version currently ahead of the latest stable version, I don’t know what happens if you attempt to make that switch. You may want to dig around a bit more before attempting the move and make sure that you have a good backup before proceeding.