VERSION obtained from source instead of the previous git tag. #4049

• Drawback: The version string is no longer a valid git identifier. For this reason the 'g' short hash prefix has been removed.
• Exception: When building directly from a tag this behaves exactly like the previous behavior. This allows formatting release versions with precision i.e. v0.9.2 This also allows arbitrary topicbranch names i.e. v0.9.1-glibc-compat

After discussion this with sipa and gmaxwell, cancel the tag part of this request. This is just to update clientversion.h.

<sipa> [00:31:35] warren: ack clientversion.h update

The version information clientversion.h isn't really used anymore; though it should be kept up to date as long as it's there. The main place of version information is in: https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L3

Note that the master branch is 0.9.99, not 0.9.0.99.

Should it be 0.9.99 if the next release from master is intended to be 0.9.2?

It won't be tagged on master. We'll make a special branch for 0.9.2 (which, in turn, will be branched from master).

@laanwj @wtogami @gmaxwell The original reason for this pull request is the confusing automatically constructed version string "0.9.0rc2-commits-hash", as previous tag in the current history is not really obvious without knowing the version tree. Ideally, it is the next tag in the branch, and the number of commits to it... but that requires knowing the future.

I propose instead to get rid of git-describe for constructing version strings, and instead use the ones from clientversion.h (plus commits and git hash) - which means we need to keep the version there in sync with prospected versions, but I think that's fine.

Opinions?

Agreed @sipa, let's just use the version from clientversion.h there. The automatically constructed versions are not helpful in our case.

@laanwj Then we're still stuck, do we accept this into master or not? Otherwise nightly builds will need commits that are not in master.

If you change this to be version 0.9.99 (which, as I said above, would be consistent with configure.ac) I'll merge it.

As requested, genbuild.sh and version.cpp are modified to obtain the client version from source instead of git tag.

If you change this to be version 0.9.99 (which, as I said above, would be consistent with configure.ac) I'll merge it.

Respectfully, I believe doing so would be illogical. You are the person who corrected me when I thought the next release from master would be 0.10 instead of 0.9.2.

Unless I made any error here this is ready to be merged. This could be cleaned up further to entirely get rid of clientversion.h but I did not want to make such an invasive change touching many source files in this PR.

How can master be 0.9.1.99, when 0.9.2 is already released? Master should be called 0.9.99.

EDIT: I'm confused, 0.9.2 is not released yet. But the plan is to do 0.9.2 in a separate branch, and keep master for 0.10 code? (@laanwj correct me if I'm wrong).

Correct @sipa. Master is pre-0.10. Master is always the breeding ground for the next major release, no matter what the next (minor) release is going to be.

For this it doesn't matter whether we want to do a 0.9.2 that includes (almost) all changes in master since 0.9.0. This will indeed be done on a seperate branch, in which we may revert some changes if they're not deemed 100% safe for release (in a minor release).

0.9.2 will be 98%-100% identical to whatever is in master at the time it branches off so I find this versioning approach to be illogical, but I don't care enough to fight it.

DO NOT MERGE. I want to improve this a bit more. I just realized that I don't want to completely break the ability to have custom -topicbranch names in tags.

VERSION obtained from source instead of the previous git tag.

• Drawback: The version string is no longer a valid git identifier. For this reason the 'g' short hash prefix has been removed.
• Exception: When building directly from a tag this behaves exactly like the previous behavior. This allows formatting release versions with precision i.e. v0.9.2 This also allows arbitrary topicbranch names i.e. v0.9.1-glibc-compat
• v0.9.99

This gives me the following error when running 'make' (Ubuntu 14.04):

$ rm src/obj/build.h
$ make -j3
...
make -C ../src leveldb/libleveldb.a
make -C ../src leveldb/libmemenv.a
../share/genbuild.sh: 25: [: db60debb4a637194cee1b7231921de808bbd8fb7: unexpected operator

I first thought it was a matter of re-running autogen and configure, but it's still there after a few tries.

Fixed by replacing the == on line 25 with =. It was a dash vs. bash issue.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/3d20cd5f61fff33fe5fffd6efddf2c942c8dd2f9 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.