Bump it to the next version (without a -dev suffix), based on the
precedent set by 70672652 (Bump to v0.6.1-dev, 2018-05-25, #834).
Previously I had VERSION there, which was a copy/paste error.
I've also added an explicit write_spec_version to release_commit.
That *should* be a no-op, with the spec version having already been
set by the previous release's dev_version_commit. But better to be
safe than to cut a release with the wrong version number in the spec
file (e.g. maybe we guessed NEXT_VERSION wrong during the last
release).
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #879
Approved by: mheon
Since 727ecfea (Use Version from spec file in setup.py, 2018-05-18, #807),
setup.py has been pulling this from a PODMAN_VERSION environment
variable (which can be set in spec files), and there's no need for us
to bump it as part of our releases.
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #879
Approved by: mheon
Matthew had expressed interest in a lovely release script on IRC.
Here's my attempt to encode the changes from the v0.5.4 release
branch. I've also added tag signing, so you may be prompted for your
passphrase during that step.
The version scheme for 0.x.y is 0.${month}.${count_that_month} [1].
We could automatically calculate those with a dozen or so lines of
shell script, but we don't think that's worth the maintenance burden
when it's easy enough for the caller to think them up on their own
[2].
The spec sed also bumps the Python package version to match, which
seems like the intended behavior until 1.0 when the Python code will
move into its own repository [3].
[1]: https://github.com/projectatomic/libpod/pull/867#issuecomment-393731907
[2]: https://github.com/projectatomic/libpod/pull/867#issuecomment-393743295
[3]: https://github.com/projectatomic/libpod/issues/786#issuecomment-390682012
Signed-off-by: W. Trevor King <wking@tremily.us>
