Quick links:
Flags
Verbs
Functions
Glossary
Release docs
How to create a new release¶
This is my checklist for making new releases.
In this example I am using version 6.2.0 to 6.3.0; of course that will change for subsequent revisions.
-
Update version found in
mlr --version
andman mlr
:- Edit
internal/pkg/version/version.go
from6.2.0-dev
to6.3.0
. - Edit
miller.spec
:Version
, andchangelog
entry - Run
make dev
in the Miller repo base directory - The ordering in this makefile rule is important: the first build creates
mlr
; the second runsmlr
to createmanpage.txt
; the third includesmanpage.txt
into one of its outputs. - Commit and push.
- Edit
-
Create the release tarball:
make release_tarball
- This creates
miller-6.3.0.tar.gz
which we'll upload to GitHub, the URL of which will be in ourmiller.spec
- Prepare the source RPM following README-RPM.md.
-
Create the Github release tag:
- Don't forget the
v
inv6.3.0
- Write the release notes -- save as a pre-release until below
- Be sure the commit being used is the (non-
main
) PR commit containing the new version, or,main
after that PR is merged back tomain
. (Otherwise, the release will be tagging the commit before the changes, andmlr version
will not show the new release number.)
- Be sure the commit being used is the (non-
- Thanks to PR 822 which introduces goreleaser there are versions for many platforms auto-built and auto-attached to the GitHub release.
- Attach the release tarball and SRPM. Double-check assets were successfully uploaded.
- Publish the release in pre-release mode, until all CI jobs finish successfully. Note that gorelease will create and attach the rest of the binaries.
- Before marking the release as public, download an executable from among the generated binaries and make sure its
mlr version
prints what you expect -- else, restart this process. - Then mark the release as public.
- Don't forget the
-
Build the release-specific docs:
- Note: the GitHub release above created a tag
v6.3.0
which is correct. Here we'll create a branch named6.3.0
which is also correct. - Create a branch
6.3.0
(notv6.3.0
). Locally:git checkout -b 6.3.0
, thengit push
. - Edit
docs/mkdocs.yml
, replacing "Miller Dev Documentation" with "Miller 6.3.0 Documentation". Commit and push. - At the Miller Read the Docs admin page, https://readthedocs.org/projects/miller, in the Versions tab, scroll down to Activate a version, then activate 6.3.0.
- In the Admin tab, in Advanced Settings, set the Default Version and Default Branch both to 6.3.0. Scroll to the end of the page and poke Save.
- In the Builds tab, if they're not already building, build 6.3.0 as well as latest.
- Verify that https://miller.readthedocs.io/en/6.3.0 now exists.
- Verify that https://miller.readthedocs.io/en/latest (with hard page-reload) shows Miller 6.8.0 Documentation in the upper left of the doc pages.
- Note: the GitHub release above created a tag
-
Notify:
- Submit
brew
pull request; notify any other distros which don't appear to have autoupdated since the previous release (notes below) - Similarly for
macports
: https://github.com/macports/macports-ports/blob/master/textproc/miller/Portfile - See also README-versions.md -- distros usually catch up over time but some contacts/pings never hurt to kick-start processes after owners move on from a project they started.
- Social-media updates.
-
Brew notes:
- How to submit a version upgrade
brew bump-formula-pr --force --strict miller --url https://github.com/johnkerl/miller/releases/download/v6.2.0/miller-6.2.0.tar.gz --sha256 xxx
withxxx
fromshasum -a 256 miller-6.2.0.tar.gz
.
- Submit
-
Afterwork:
- Edit
internal/pkg/version/version.go
to change version from6.3.0
to6.3.0-dev
. make dev
- Commit and push.
- Edit