Better commit messages for the changelog


(oblio) #1

Hi guys,

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 Commits · discourse/discourse · GitHub. 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

Thank you for bearing with me :slight_smile:


(Joshua Rosenfeld) #2

Did you check out the pinned #dev topic?

There already is a convention in place. Whether it is used…that’s a different issue.


(oblio) #3

Oh, sorry I missed the pinned topic. I can delete my topic since it seems to be redundant now.

I just went by what I saw on Github… and only a handful of commit messages follow that convention, as far as I can see.


(Joshua Rosenfeld) #4

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.


(Jeff Atwood) #5

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.


(oblio) #6

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.

My 2 euro cents :slight_smile:


(Wes Osborn) #7

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.


(oblio) #8

Thanks @wesochuck for the great pointer!

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”).


(Wes Osborn) #9

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.


(oblio) #10

Assuming security fixes are merged into stable as well, I think I’ll switch to stable.


(cpradio) #11

They are. High security items are backported to stable, otherwise, it occurs every 3 months (roughly)


(Wes Osborn) #12

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.


(oblio) #13

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?


(Wes Osborn) #14

Confirmed that it looks like you need to wait till the stable release that would put you ahead of your current beta release:


(cpradio) #15

It used to be tests-passed, which is/was much more volatile. They switched it to beta to give it more stability.

The idea is beta should be fairly safe, yes it gets a lot of changes (weekly merges, etc), but most of the time is is complete new features.

Stable is for those who really do not want any regular updates (except for security).

Plus by having a lot of customers run on beta they can vet out some edge case issues with new features, like tag auto-complete, et al.


(oblio) #16

It seems fair that free users are used as beta-testers, but they should be warned about it :stuck_out_tongue:


(Jeff Atwood) #17

Stable is not really all that “stable”, it’s just not changing. Change = risk.