.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body

   1 On Tue, Nov 17, 2009 at 05:53:31PM -0500, Chris Ball wrote:
   2 >   > It would make it much easier on the Debian package maintainer if
   3 >   > the Bugs Everywhere project would make conventional tarball
   4 >   > releases, with conventional version numbers, with a changelog
   5 >   > describing what has changed between versions.
   6 > How do people feel about pushing for a 1.0 release, with Trevor's tree
   7 > plus a finished cfbe merge?  Or would we rather wait until afterwards
   8 > to try for cfbe?
   9
  10 Sounds good to me.  Not that my tree is much ahead of the trunk at the
  11 moment.  We've talked over most of these issues a few times, so I'll
  12 just summarize where I think we stand on the steps needed to make a
  13 release.
  14
  15 ** cfbe integration
  16
  17 Postpone until we work out bzr/hg versioning [1]?
  18
  19 ** Conventional version number
  20
  21 Set to "1.0.0" using libbe.version._VERSION.
  22
  23 ** NEWS file
  24
  25 Depending on our level of masochism, either something starting out
  26 along the lines of [2]
  27   bzr log --gnu-changelog -n1 -r 200..
  28 (commit 200, or
  29   aaron.bentley@utoronto.ca-20060411035623-9b8d222282a26ce1
  30  was the last time anyone touched the NEWS file),
  31 or a much abbreviated entry [3,4], along the lines of my current NEWS
  32 file (changed just a few minutes ago).
  33
  34 ** Tag bzr commit
  35
  36   bzr tag 1.0.0
  37
  38 ** Create tarball
  39
  40 From Ben[5]:
  41   bzr export /tmp/be-1.0.0.tar.gz
  42
  43
  44 References:
  45
  46 [1]
  47 On Thu, Jul 23, 2009 at 05:38:03PM -0400, Steve Losh wrote:
  48 > On Jul 21, 2009, at 9:59 AM, W. Trevor King wrote:
  49 > > Steve's also versioning it with Mercurial.  Will he mind changing to
  50 > > Bazaar?
  51 >
  52 > Yeah, I've tried bazaar but really don't like the interface at all.  If
  53 > everyone else really wants me to move it over I guess I can though.
  54
  55 [2]
  56 On Tue, Jul 14, 2009 at 11:05:38AM -0400, Chris Ball wrote:
  57 > Actually, there's a `bzr log --gnu-changelog` now, and `bzr help
  58 > log-formats` offers some more styles.  (None of them seem to match
  59 > my preferred style for release announcements exactly, which would
  60 > be `git shortlog`-style.)
  61
  62 [3]
  63 On Thu, Jul 16, 2009 at 07:21:10PM +1000, Ben Finney wrote:
  64 > I actually don't think the commit log needs to be part of the release at
  65 > all. It's of interest only to those who want fine-level detail about
  66 > changes to every file, and for that purpose I think read access to the
  67 > VCS is much better. Packaging a static copy of the commit log as plain
  68 > text seems pointless.
  69 >
  70 > Rather, we should treat a user-changes level “NEWS” file (or whatever
  71 > name we choose for it) as part of the documentation, and set the
  72 > expectation among the team that it will be updated for each user-visible
  73 > change being worked on, like any other documentation.
  74
  75 [4]
  76 On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote:
  77 > Hi,
  78 >
  79 >    > That's not a changelog, that's a commit log of every source-level
  80 >    > commit made. Far too much detail for a changelog of
  81 >    > *user-visible* changes associated with a release.
  82 >
  83 > I think I agree with both of you. :) It seems like it's both true that
  84 > there's no point in keeping a GNU-style ChangeLog these days, and that
  85 > if we make a release we should write an announce mail that directly
  86 > mentions new user-visible changes as well as attaching the commit log.
  87 > That smaller list of highly user-visible changes could live in NEWS,
  88 > or in the announce mail, or both.
  89
  90 [5]
  91 On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
  92 > Even better: ‘bzr export /tmp/foo.tar.gz’ will create a source tarball
  93 > of all the files in the branch's VCS inventory. All we need to do is
  94 > start the practice of tagging a release in the VCS, and export the
  95 > tarball at that time.
  96
  97 --
  98 This email may be signed or encrypted with GPG (http://www.gnupg.org).
  99 The GPG signature (if present) will be attached as 'signature.asc'.
 100 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
 101
 102 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt