.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body

   1 I don't think anyone's changing their mind ;), so tallying the
   2 comments so far:
   3
   4 On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
   5 > I still disagree that a timestamp is the right thing to use there. If
   6 > you want a monotonically-increasing indicator of which revision we're up
   7 > to, that's immediately available with the revision number from VCS on
   8 > the main branch. That also has the advantage of producing consecutive
   9 > numbers for each revision, by definition.
  10
  11 +1 for trunk version number.
  12
  13 On Tue, Jul 14, 2009 at 05:27:52PM +0200, Elena of Valhalla wrote:
  14 > I also have a weak preference for version numbers, as long as they
  15 > give useful informations on the state the release.
  16
  17 +1 for trunk version number.
  18
  19 On Tue, Jul 14, 2009 at 02:29:10PM -0400, Aaron Bentley wrote:
  20 > We don't do that.  We have official releases every 4 weeks, but we do
  21 > believe that running bzr.dev is pretty safe, because it's always tested
  22 > and our test suite is quite thorough.
  23
  24 +1 for by hand version bumps.
  25
  26 On Fri, Jul 17, 2009 at 11:37:49PM +0200, Gianluca Montecchi wrote:
  27 > The version number of trunk _is_ should be the official version number of the
  28 > Bugs Everywhere releases.
  29 > The version number in branch does not means nothing outside the branch.
  30 > At least we can have a mechanism to build a version number scheme that is
  31 > consistent for us to be able to merge branch easily.
  32
  33 +1 for trunk version number.
  34
  35 And me with my timestamps ;).
  36
  37 Sounds like we should go with trunk version number, but that it should
  38 be set by hand whenever Chris decides to release something, since the
  39 rest of us don't know what version the trunk is on.  Unless we do
  40 something like:
  41   bzr log -n 0 | grep -B2 'nick: be$' | head -n1 | sed 's/ *revno: \([0-9]*\).*/\1/'
  42 to extract the last trunk commit referenced from our branch.
  43
  44 Implementation preferences? (i.e. Chris vs. regexp matching :p)
  45
  46 --
  47 This email may be signed or encrypted with GPG (http://www.gnupg.org).
  48 The GPG signature (if present) will be attached as 'signature.asc'.
  49 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
  50
  51 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt