.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body

   1 On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote:
   2 > "W. Trevor King" <wking@drexel.edu> writes:
   3 >
   4 > > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
   5 > > > "W. Trevor King" <wking@drexel.edu> writes:
   6 > > >
   7 > > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
   8 > > > > > Please, no. Timestamps aren't version strings, that's conflating
   9 > > > > > two pieces of information with very different meanings.
  10 > > > > > Correlating the two is the job of a [NEWS file].
  11 > >
  12 > > > If you want a monotonically-increasing indicator of which revision
  13 > > > we're up to, that's immediately available with the revision number
  14 > > > from VCS on the main branch. That also has the advantage of
  15 > > > producing consecutive numbers for each revision, by definition.
  16 > >
  17 > > But not during branch-switches, while my method skips large regions,
  18 > > but probably increases during any reasonable branch-switch.
  19 >
  20 > I've read this several times now, and I don't see what it's saying.
  21 >
  22 > The assumption I'm making is that there is a single canonical “main
  23 > branch”, from which releases will be made.
  24
  25 I don't think you need to assume this.  See my "virtual branch"
  26 argument below.
  27
  28 > The version number set in that branch is the one which determines
  29 > the version of Bugs Everywhere as a whole.
  30
  31 If you are suggesting that the dev branches adjust their release
  32 number _by_hand_ to match the current trunk release number, that
  33 allows switching, but sounds like a lot of work and isn't correct
  34 anyway, since they are not in the same state as the trunk.
  35
  36 > The revision number is only useful in the context of the branch, so it
  37 > only matters when comparing versions within a branch. When you switch
  38 > between branches, if you're interested in the revision number you'll
  39 > still need to know which branch you're talking about.
  40
  41 I think this is our main disagreement.  I see all the branches as part
  42 of the same codebase, with monotonically increasing timestamp patch
  43 numbers.  If you were to collapse all the commit snapshots down into a
  44 single chronological "virtual branch", it would still make sense, it
  45 would just be a bit unorganized.  We do all try to move in the same
  46 general direction ;).
  47
  48 > Switching between branches doesn't change the canonical version string.
  49
  50 Different released code should have different version numbers.
  51
  52 > > For example, when I upgraded to rich root to pull Ben's patch, I'm not
  53 > > sure if Chris upgraded the trunk and merged my branch, or just ditched
  54 > > the trunk and cloned my branch. Using actual bzr revision numbers
  55 > > would make switching branches that either wrong (in the case of rev-id
  56 > > decreases) or confusing (in the case of a single non-consecutive
  57 > > increase).
  58 >
  59 > This, then, is an argument for not having the revision number in the
  60 > version string at all. The version then becomes a more traditional
  61 > “major.minor.patch” tuple, and is only ever updated when some release
  62 > manager of the canonical branch decides it's correct to do so.
  63
  64 It is an argument for not using the revision number.  You can avoid
  65 revision numbers by using hand-coded patch numbers, or by using
  66 timestamps, which is what we're trying to decide on :p.
  67
  68 > If we use the ‘bzr version-info --format=python > foo_version.py’
  69 > command in some build routine, the branch's revision number will be
  70 > available directly within Python by importing that module. That would
  71 > allow it to be output in some UI, if that's what you're interested in
  72 > seeing.
  73
  74 True.  Which means that whichever version string wins out, the other
  75 side will still be able to access the info we both want included ;).
  76 We can certainly suggest that bug reporters submit their
  77   be --verbose-version
  78 when they submit bugs.  The only role of the official "version string"
  79 is to make life easy for packagers.  If they woln't be switching
  80 branches, then either of our proposals are fine.  If they will, then
  81 I think timestamps work better.
  82
  83 --
  84 This email may be signed or encrypted with GPG (http://www.gnupg.org).
  85 The GPG signature (if present) will be attached as 'signature.asc'.
  86 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
  87
  88 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt