.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body

   1 On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
   2 > "W. Trevor King" <wking@drexel.edu> writes:
   3 > > I've switched my branch over to the current url, and moved to
   4 > > last-commit-timestamp version numbers.
   5 >
   6 > Please, no. Timestamps aren't version strings, that's conflating two
   7 > pieces of information with very different meanings. Correlating the two
   8 > is the job of a changelog.
   9
  10 Which we don't bother keeping (also NEWS), since "bzr log" works so nicely.
  11 If you really want an standard changelog, see
  12   http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html
  13
  14 > > This removes the "prefered branch" issues with the old scheme, and
  15 > > version numbers should increase monotonically
  16 >
  17 > The English word “should” is ambiguous in this context. Are you saying
  18 > this is desirable, or are you predicting that it will likely be the
  19 > case?
  20
  21 Both.
  22
  23 > I don't see how it's either, so am doubly confused :-)
  24
  25 The timestamp should at least replace the patch release number, which
  26 you agree is-desirable-to increase motonically ;).  I also predict
  27 that it will increase monotonically for any given branch, since the
  28 branch HEAD will have both the most recent commit and the highest
  29 version number.  The only problem I can think of is having your clock
  30 _way_ off, and that is unlikely enough to ignore.  If you hop between
  31 branches, the timestamp is much more likely to increase going to the
  32 more modern branch than the bzr revision number, which desynchronize
  33 between branches fairly quickly.
  34
  35 > The convention for three-part version strings is often:
  36 >
  37 >   * Major release number (big changes in how the program works,
  38 >     increasing monotonically per major release, with “0”indicating no
  39 >     major release yet)
  40 >
  41 >   * Minor release number (smaller impact on how the program works,
  42 >     increasing monotonically per minor release, with “0” indicating no
  43 >     minor release yet since the previous major)
  44 >
  45 >   * Patch release number (bug-fix and other changes that don't affect
  46 >     the documented interface, increasing monotonically per patch
  47 >     release, with “0” indicating no patch release since the previous
  48 >     major or minor)
  49
  50 One problem is that we don't actually have "releases".  People just
  51 clone a branch, install, and go.  If you're worried about stability,
  52 just clone from a more stable branch (i.e., Chris' trunk).  I think
  53 this is good for distributed development, but maybe makes it hard to
  54 package into a conventional release-based system.  With the bzr patch
  55 number in setup.py as the patch release number, I would be releasing
  56 my 0.1.363 while Chris releases his 0.1.314, even though they're at
  57 about the same point.  I would rather be releasing my
  58   0.1.20090714121347
  59 while Chris releases his
  60   0.1.20090713154540
  61 Since then the similarity is clearer.
  62
  63 At any rate, I think the two approaches are close enough that an
  64 auto-updating timestamp beats a manually bumped patch number, since
  65 no-one ever actually bumps the patch number ;).
  66
  67 --
  68 This email may be signed or encrypted with GPG (http://www.gnupg.org).
  69 The GPG signature (if present) will be attached as 'signature.asc'.
  70 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
  71
  72 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt