[API] [Workbench1] [SDKs] ruby gems report wrong version number
- sdk/ruby/arvados.gemspec reports itself as 1.4.1.timestamp1
- services/api/Gemfile pins an arvados gem version by commit hash, and bundler writes "1.4.1.timestamp1" in Gemfile.lock
- bundler succeeds at version 1.4.1.timestamp2
- sometime later, a 1.4.2 tag is added somewhere in the repo
- checkout version 1.4.1.timestamp2 and run bundler
- bundler checks out the specified git hash, but the resulting arvados.gemspec now reports itself as 1.4.2.timestamp1
- bundler fails at version 1.4.1.timestamp2
The "use git tag to figure out version at runtime" code used to use the latest tag reachable from HEAD, which makes recent/dev versions appear older than they really are (e.g., 1.4.2 isn't an ancestor of master) -- then it changed in ff48e70fd7cc41997a27c0b04bb38149a6abfa0d to report the highest version in the repo, which makes older/released versions appear newer than they really are.
- If this commit is tagged -- the current version is the tag name.
- If this commit IS NOT an ancestor of master, and x.y.z is the nearest tagged ancestor of this commit -- the current version is x.y.(z+1).preTIMESTAMP
- If this commit IS an ancestor of master, and x.y.z is the largest version tag that is NOT a descendant of this commit -- the current version is x.(y+1).0.preTIMESTAMP
With this scheme, version-tagging an ancestor of a pinned version can still break old builds -- but tagging later versions is OK.
- Status changed from New to In Progress
- Assigned To set to Tom Clegg
- Target version changed from 2020-01-02 Sprint to 2019-12-04 Sprint
#3 Updated by Ward Vandewege 7 months ago
The version number generated on unmerged feature branches is a bit odd (last tag on master x.y.z => x.y.z+1-pre$TIMESTAMP) which is 1.3.1-preYYYYMMDD at the moment because 1.3.0 is the last tag that is on master and not in a version branch. In practice this doesn't matter much, it only affects dev builds and it doesn't break them.