One common release engineering pattern is to have a release script which builds, runs tests, bumps the version by removing -dev from the version in a commit, tags it, build/hashes/signs/releases artifacts and then really bumps the {{next minor ver}}-dev version in a new commit on master and finally pushes commits and tag. Then, it ends up that master will usually contain a -dev version (and is always stable) and releases are non-dev. Bonus points for gpg signing commits and tags, and using signed-of-by.
On 09/30/2016 11:04 AM, Alexander Belopolsky wrote:
>
> There would be little harm in keeping the version in the repository's
> Makefile as well.
I'm afraid I see some harm. Yes, bumping the release could be done
automatically or semiautomatically as part of a release procedure, along
the lines that Paul Koning suggested. But this would mean that the only
time the repository Makefile's version number would be correct would be
near the time of a release; at most other points of time the version
number would be wrong, and this would be confusing. Also, it would mean
that bumping the release would not be an atomic operation, as it is now.
I'm also worried that downstream distributors will modify the data but
still call it "2016g". We are considering installing the version number
along with the other data; if we do that, this mislabeling problem will
get worse because the wrong label will become part of the runtime
environment, and having the wrong version number in a development
Makefile will likely contribute to the mislabeling.