Meaningful version numbers based on dry run (testnet version)

[drltc]

Since this repository has no tags, my pull request https://github.com/BitShares/bitshares_toolkit/pull/764 will display version numbers for releases from this repository as "unknown".

I propose using the number of commits since the last dry run bump as a basis for version numbering. E.g. current develop would be dryrun-25-28-gbb0f1c3 because it is the 28th commit past the commit that bumped the dry run number to 25.

For your convenience, here is the first release in which each testnet version appeared:

git tag dryrun-16 d17ac54b894621e752f2a093d9514beadcd44bae
git tag dryrun-17 e1dec2da74d3f79b7970dd6bb98f94f9285704e2
git tag dryrun-18 483400f710755e8a003b287dd49b6cd15eda5308
git tag dryrun-19 6bd252eeea2dec21c08d9b51d9a490204a881e2d
git tag dryrun-20 2ff8deb92047699409e21cba76800c43f3b71563
git tag dryrun-21 4cb49f449fe6b89c819d9024816789d498f465fd
git tag dryrun-22 6af4fc06cacdfed48de1b2369b9917dc6c0b42b8
git tag dryrun-23 fe102c333a5e087a1e7adf835e77980b56ff4e59
git tag dryrun-24 b5b2b3cb7756c11aa914583b4cfcfe1c7f69eee6
git tag dryrun-25 17d2f881f050734f76f8ca31dbfac2dfa256fac8

I used the following script getbumps.sh to come up with these commit hashes:

#!/bin/sh
git log --pretty="%H" --reverse |
while read chash
do
    testnet_version=$( (git show $chash:libraries/blockchain/include/bts/blockchain/config.hpp | grep BTS_TEST_NETWORK_VERSION | grep -o '[0-9]\+\s*$') || echo 0 )
    echo $chash $testnet_version
done

In particular I piped the output of getbumps.sh to the following Python script getbumps.py:

#!/usr/bin/env python3

import sys

s = set(["0"])

for line in sys.stdin:
    chash, testnet_version = line.split()
    if testnet_version not in s:
        s.add(testnet_version)
        print("git tag dryrun-{} {}".format(testnet_version, chash))

The output of ./getbumps.sh | ./getbumps.py should match my list of tags above. The commit labeled as dryrun-16 may not actually be the earliest commit in which a BTS_TEST_NETWORK_VERSION of 16 appeared, and earlier dryruns weren't found by the script. I'm guessing at some point there was some re-organization that caused the config.hpp to be moved to its current location from elsewhere in the tree.

If anyone cares enough about earlier dry runs to tag them, they're welcome to submit their own contribution :)

[vikramrajkumar]

One issue is that BTS_TEST_NETWORK_VERSION was put in simply as a hack to try to avoid an unresolved bug in our fork switching code (see #634). It is used to automatically change the default ports and client data directory path on test networks. I would like to remove it and just use BTS_CLIENT_VERSION everywhere.

It does not correspond to what we have labeled "dry runs" in the forum (e.g. we never had a "Dry Run 25").

In fact, given your #764, I think we should always use the latest git tag everywhere and follow your algorithm:

• If the current commit is tagged, then the tag name becomes the version string.
• Else if we are N commits past the last tag T, then the version number is equal to $T-$N-g$H where H is the first few characters of the current commit hash.
• Else the version string is "unknown".

Thoughts?

[drltc]

Using the latest git tag everywhere means this repo must have at least one git tag. As you can see at https://github.com/BitShares/bitshares_toolkit/releases this repo has no git tags. Only the dacsunlimited repo has tags.

I wrote that script to try to create some meaningful tags for historical versions without too much work. If you want to tag historical versions differently, or if you don't want to tag historical versions at all and only make tags for current or future versions, that's fine.

But we need at least one tag, otherwise the version will simply be "unknown".

Regardless of what we do with historical releases, I would support the following policy going forward:

• Whenever dacsunlimited releases version tag T, the latest commit in this repo which is included in the dacsunlimited release is tagged with the same tag T.

With regard to BTS_CLIENT_VERSION: That macro only has meaningful version information in the dacsunlimited repo. In this upstream repo, it is simply testnet -- and I assume it has been testnet since forever. I would support putting some version information in BTS_CLIENT_VERSION, if it breaks nothing (or if we are willing to fix whatever it breaks). That would help us going forward (but of course do nothing for historical releases).

We would probably like some way to keep BTS_CLIENT_VERSION and the tag in sync.

Maybe adding a check to stop the build if BTS_CLIENT_VERSION doesn't match the tag. Or even simpler, let BITSHARES_TOOLKIT_GIT_REVISION_DESCRIPTION be the canonical source of version information:

#define BTS_CLIENT_VERSION (BITSHARES_TOOLKIT_GIT_REVISION_DESCRIPTION "-testnet")

[vikramrajkumar]

I've added tags for all the dry runs: https://github.com/BitShares/bitshares_toolkit/releases

Timestamps are of the time I tagged them rather than the commit however; I will update that later.

And I've changed the client version to be what's reported by git describe --tag per your patch, with another suffix when BTS_TEST_NETWORK_VERSION is defined: https://github.com/BitShares/bitshares_toolkit/commit/eaebfedfff8928fa8f6473445d3ac9f7a211b13a

So for example, my client currently reports:

~/bitshares_toolkit/programs/client (develop ✔) ᐅ ./bitshares_client --version
{
  "blockchain_name": "BitShares XTS",
  "blockchain_description": "BitShares X Test Network",
  "client_version": "dryrun-17-442-geaebfed-testnet-25",
  "bitshares_toolkit_revision": "eaebfedfff8928fa8f6473445d3ac9f7a211b13a",
  "bitshares_toolkit_revision_age": "23 minutes ago",
  "fc_revision": "55e7a073cf7ab19b88f90ffceba24c70e0c7b1c4",
  "fc_revision_age": "49 hours ago",
  "compile_date": "compiled on Sep 11 2014 at 16:59:08"
}

[drltc]

We might also want to look into using signed annotated tags, see http://git-scm.com/book/en/Git-Basics-Tagging and http://stackoverflow.com/questions/4971746/why-should-i-care-about-lightweight-vs-annotated-tags