Bug #15900

[API] [Workbench1] [SDKs] ruby gems report wrong version number

Added by Tom Clegg 7 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
12/03/2019
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release relationship:
Auto

Description

Example:
  • 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.


Subtasks

Task #15903: Review 15900-gem-versionResolvedWard Vandewege

Associated revisions

Revision b702e93a
Added by Tom Clegg 7 months ago

Merge branch '15900-gem-version-142' into 1.4-dev

refs #15900

Arvados-DCO-1.1-Signed-off-by: Tom Clegg <>

Revision 32d4f9f5
Added by Tom Clegg 7 months ago

Merge branch '15900-gem-version'

refs #15900

Arvados-DCO-1.1-Signed-off-by: Tom Clegg <>

Revision cc4f77d7 (diff)
Added by Peter Amstutz 6 months ago

Support Debian 8 refs #15900

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <>

History

#1 Updated by Tom Clegg 7 months ago

Proposed version detection scheme:
  1. If this commit is tagged -- the current version is the tag name.
  2. 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
  3. 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.

#2 Updated by Tom Clegg 7 months ago

  • 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

LGTM.

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.

#4 Updated by Tom Clegg 7 months ago

  • Target version changed from 2019-12-04 Sprint to 2020-01-02 Sprint

#5 Updated by Tom Clegg 7 months ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF