Project

General

Profile

Actions

Bug #15900

closed

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

Added by Tom Clegg almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
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 1 (0 open1 closed)

Task #15903: Review 15900-gem-versionResolvedWard Vandewege12/03/2019Actions
Actions #1

Updated by Tom Clegg almost 5 years 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.

Actions #2

Updated by Tom Clegg almost 5 years 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
Actions #3

Updated by Ward Vandewege almost 5 years 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.

Actions #4

Updated by Tom Clegg almost 5 years ago

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

Updated by Tom Clegg almost 5 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF