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 Fri, Sep 30, 2016 at 11:53 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
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.