.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body

   1 On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
   2 > * W. Trevor King (wking@drexel.edu) wrote:
   3 > > One problem is that we don't actually have "releases".  People just
   4 > > clone a branch, install, and go.
   5 >
   6 >   This is actually the main reason I've manually mirrored the tree in
   7 > the past, so that users of our projects can get BE.  If tarballs were
   8 > available I probably wouldn't even bother, but bzr really isn't a nice
   9 > dependency for just submitting/commenting on bugs.
  10
  11 Fair enough.  It will be good when we get a commit-able web interface
  12 and/or email interface going.
  13
  14 >   Isn't there a bzr web interface that at least supports creating
  15 > tarballs/zips?  It is pretty standard functionality for most other VCS'
  16 > web interfaces so I'm guessing there must be, but loggerhead seems not
  17 > to support it.
  18
  19 Unfortunately, people would still need bzr to install the versioned source:
  20
  21   libbe/_version.py:
  22           bzr version-info --format python > $@
  23
  24 So you'll need a "release" target in the makefile to build a bzr-less
  25 install.  While you're at it, you should probably compile the manpage
  26 too to remove the docbook-to-man dependency.
  27
  28 Do people want a HEAD tarball too?  There must be a bzr equivalent of
  29   .git/hooks/post-update
  30 but I don't know what it is.
  31
  32 > > If you're worried about stability, just clone from a more stable branch
  33 > > (i.e., Chris' trunk).  I think > this is good for distributed development,
  34 > > but maybe makes it hard to package into a conventional release-based system.
  35 > > With the bzr patch number in setup.py as the patch release number, I would be
  36 > > releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at
  37 > > about the same point.  I would rather be releasing my
  38 > >   0.1.20090714121347
  39 > > while Chris releases his
  40 > >   0.1.20090713154540
  41 > > Since then the similarity is clearer.
  42 >
  43 >   Both approaches seem pretty odd to me, as a user you would have no
  44 > idea if 0.1.200910302359 has the fixes you required in a release you
  45 > were using that was numbered 0.1.200907141554.  Surely you'd at least be
  46 > {pre,suf}fixing a branch name to the version.
  47
  48 "be --version" currently gives you the revision id:
  49   wking@drexel.edu-20090714121347-c6rloikst1t3m5yl
  50 which tells you exactly which commit your installed version is based on.
  51 If we want stick with revision numbers, how about:
  52   major.minor.revno-branch_nick
  53 But then we'd have to pick "unique" branch nicknames...
  54
  55 I'd sliced out the timestamp portion of the revision id so that the
  56 "patch-number" would be an integer and the branch name wasn't
  57 references, so that "upgrading" from one branch to another could be
  58 transparent to the users (who just see an increading timestamp), but
  59 still available to the developers (who know when commits were made to
  60 the branches they track, and the likelyhood of to-the-second commit
  61 collisions in official packages is small).
  62
  63 On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
  64 > "W. Trevor King" <wking@drexel.edu> writes:
  65 >
  66 > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
  67 > > > Please, no. Timestamps aren't version strings, that's conflating two
  68 > > > pieces of information with very different meanings. Correlating the
  69 > > > two is the job of a changelog.
  70 > >
  71 > > Which we don't bother keeping (also NEWS), since "bzr log" works so
  72 > > nicely.
  73 >
  74 > That's not a changelog, that's a commit log of every source-level commit
  75 > made. Far too much detail for a changelog of *user-visible* changes
  76 > associated with a release.
  77
  78 I need a user around to help me determine "user-visable" changes ;).
  79 My labmates loose interest after be init/new/comment :p.  None of
  80 which has ever changed, other than set-root -> init ;).
  81
  82 > > The timestamp should at least replace the patch release number, which
  83 > > you agree is-desirable-to increase motonically ;).
  84 >
  85 > I still disagree that a timestamp is the right thing to use there. If
  86 > you want a monotonically-increasing indicator of which revision we're up
  87 > to, that's immediately available with the revision number from VCS on
  88 > the main branch. That also has the advantage of producing consecutive
  89 > numbers for each revision, by definition.
  90
  91 But not during branch-switches, while my method skips large regions,
  92 but probably increases during any reasonable branch-switch.  For
  93 example, when I upgraded to rich root to pull Ben's patch, I'm not
  94 sure if Chris upgraded the trunk and merged my branch, or just ditched
  95 the trunk and cloned my branch.  Using actual bzr revision numbers
  96 would make switching branches that either wrong (in the case of
  97 rev-id decreases) or confusing (in the case of a single
  98 non-consecutive increase).
  99
 100 On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote:
 101 >    > I agree that's a problem. I think the solution is to start making
 102 >    > releases, with specific version strings, as source tarballs.
 103 >
 104 > I'm happy to do this if people think it would be useful, and I don't
 105 > yet have a strong opinion on whether the releases should come with
 106 > version numbers or timestamps.
 107
 108 I imagine the news from 2006 to now will be somewhat abridged ;).
 109
 110 --
 111 This email may be signed or encrypted with GPG (http://www.gnupg.org).
 112 The GPG signature (if present) will be attached as 'signature.asc'.
 113 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
 114
 115 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt