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.
The checkin prefix conventions are used – no idea what you two are on about.
If the change is trivial, we don’t feel obligated to add a prefix. The prefix is for larger changes. For example, if I copyedit a single sentence changing it from
The quick brown fox jumps over the lazy dog
to
The quick brown fox jumped quickly over the lazy dog
That is not gonna be prefixed with FIX: or anything of the sort.
Hmmm… the thing is, let’s say I’m a Discourse admin. Going through all the commits is no fun.
There should be a more professional-looking changelog somewhere, IMO.
As a Discourse admin I’d like to be able to make an informed decision on updating and all the noise in the git log is not helping with that.
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.
I have a follow-up question: what happens then with the point updates? Should I bother with them? Especially since their naming makes me a bit worried (“beta”).
You may want to consider switching to the stable branch. Note, I don’t think that it is possible to go from stable back to beta, so make sure this really what you want to do before proceeding.
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.
Is there any reason why the default installation instructions for Discourse do not lead you to stable?
The only reason I can think of is that Discourse is still developing so fast that you want users to get the latest fixes, but IMO this would warrant the use of a sub-1.0 version.
Or it’s just that no one got around to switching the default installation to stable?
