<div style="white-space:pre-wrap">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. </div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 30, 2016 at 11:53 AM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/30/2016 11:04 AM, Alexander Belopolsky wrote:<br>
><br>
> There would be little harm in keeping the version in the repository's<br>
> Makefile as well.<br>
<br>
I'm afraid I see some harm. Yes, bumping the release could be done<br>
automatically or semiautomatically as part of a release procedure, along<br>
the lines that Paul Koning suggested. But this would mean that the only<br>
time the repository Makefile's version number would be correct would be<br>
near the time of a release; at most other points of time the version<br>
number would be wrong, and this would be confusing. Also, it would mean<br>
that bumping the release would not be an atomic operation, as it is now.<br>
<br>
I'm also worried that downstream distributors will modify the data but<br>
still call it "2016g". We are considering installing the version number<br>
along with the other data; if we do that, this mislabeling problem will<br>
get worse because the wrong label will become part of the runtime<br>
environment, and having the wrong version number in a development<br>
Makefile will likely contribute to the mislabeling.<br>
<br>
</blockquote></div>