Adds a shell script that automates most of the work involved in tagging releases. The only thing it doesn't do is git push, because a manual check that everything worked before publishing the tag is obviously a good thing.
The script has one slight advantage over what we're using elsewhere, in that the order of entries in the changelog will always be sane, even when we're tagging patch releases for older trains. That's because the step for updating the changelog inserts the summary immediately before the preceding tag, rather than always putting it at the top of the file regardless of where we are in the tree.
There are three other, small differences in the changelog:
I removed the leading v from the version in the section headings (it's still present in the tag itself), to match the style in our other changelogs.
The date will not be inserted for future releases, because I wasn't sure of a reliable, portable way to format the date across all Linux/Unix flavours. I figure it's not a big deal because the date and time show up in git log and on GitHub anyway.
I removed the empty anchor tags because we don't need them/they don't even show up on GitHub (presumably they're there for the benefit of some other platform). I dislike them because they're kind of ugly for anyone viewing the file as text.
These are all of the steps that the script performs, in order:
Identify the last tag that precedes HEAD, assign it to LAST_TAG.
Get the list of intervening one-line commit messages from git log $LAST_TAG..HEAD.
Parse each commit message in turn, building up summary sections for the commit log. This includes an Other changes section for any commits that don't match one of the recrognised formats.
Split $LAST_TAG and bump the appropriate part, then assemble the bumped tag as NEW_TAG.
Update Cargo.toml and Cargo.lock with $NEW_TAG.
Insert the summary for $NEW_TAG into the changelog, immediately before the summary for $OLD_TAG.
Commit the changes.
Tag the release.
Lastly, I wonder if some of you might be unhappy that we've written this ourselves rather than using a 3rd-party tool. I get where you're coming from, but fwiw this script is almost a verbatim copy (ref) of something I've been using in all my side-projects for the last couple of years. So it's reasonably battle-hardened at this point, although I'm sure there are still lots of exciting bugs for us to discover when we run it on different machines to mine. :grin:
Fixes #214.
Adds a shell script that automates most of the work involved in tagging releases. The only thing it doesn't do is
git push, because a manual check that everything worked before publishing the tag is obviously a good thing.The script has one slight advantage over what we're using elsewhere, in that the order of entries in the changelog will always be sane, even when we're tagging patch releases for older trains. That's because the step for updating the changelog inserts the summary immediately before the preceding tag, rather than always putting it at the top of the file regardless of where we are in the tree.
There are three other, small differences in the changelog:
I removed the leading
vfrom the version in the section headings (it's still present in the tag itself), to match the style in our other changelogs.The date will not be inserted for future releases, because I wasn't sure of a reliable, portable way to format the date across all Linux/Unix flavours. I figure it's not a big deal because the date and time show up in
git logand on GitHub anyway.I removed the empty anchor tags because we don't need them/they don't even show up on GitHub (presumably they're there for the benefit of some other platform). I dislike them because they're kind of ugly for anyone viewing the file as text.
These are all of the steps that the script performs, in order:
Identify the last tag that precedes
HEAD, assign it toLAST_TAG.Get the list of intervening one-line commit messages from
git log $LAST_TAG..HEAD.Parse each commit message in turn, building up summary sections for the commit log. This includes an
Other changessection for any commits that don't match one of the recrognised formats.Split
$LAST_TAGand bump the appropriate part, then assemble the bumped tag asNEW_TAG.Update
Cargo.tomlandCargo.lockwith$NEW_TAG.Insert the summary for
$NEW_TAGinto the changelog, immediately before the summary for$OLD_TAG.Commit the changes.
Tag the release.
Lastly, I wonder if some of you might be unhappy that we've written this ourselves rather than using a 3rd-party tool. I get where you're coming from, but fwiw this script is almost a verbatim copy (ref) of something I've been using in all my side-projects for the last couple of years. So it's reasonably battle-hardened at this point, although I'm sure there are still lots of exciting bugs for us to discover when we run it on different machines to mine. :grin:
@mozilla/fxa-devs r?