I imported a few threads from the mailing list as wishlist bugs.

12c:uw: Bug aggregation.  Multi-repo meta-BE?
529:ow: How should we version BE?
2f0:aw: Static html report generation
22b:aw: Sorting targets chronologically
d99:aw: CherryPy interface "Cherry-flavored BE"
e08:aw: Interactive email interface

1 files changed, 88 insertions, 0 deletions

diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body
new file mode 100644
index 0000000..5eeb353
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body
@@ -0,0 +1,88 @@
+On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+> 
+> > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > > "W. Trevor King" <wking@drexel.edu> writes:
+> > > 
+> > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > > Please, no. Timestamps aren't version strings, that's conflating
+> > > > > two pieces of information with very different meanings.
+> > > > > Correlating the two is the job of a [NEWS file].
+> >
+> > > If you want a monotonically-increasing indicator of which revision
+> > > we're up to, that's immediately available with the revision number
+> > > from VCS on the main branch. That also has the advantage of
+> > > producing consecutive numbers for each revision, by definition.
+> > 
+> > But not during branch-switches, while my method skips large regions,
+> > but probably increases during any reasonable branch-switch.
+> 
+> I've read this several times now, and I don't see what it's saying.
+> 
+> The assumption I'm making is that there is a single canonical “main
+> branch”, from which releases will be made.
+
+I don't think you need to assume this.  See my "virtual branch"
+argument below.
+
+> The version number set in that branch is the one which determines
+> the version of Bugs Everywhere as a whole.
+
+If you are suggesting that the dev branches adjust their release
+number _by_hand_ to match the current trunk release number, that
+allows switching, but sounds like a lot of work and isn't correct
+anyway, since they are not in the same state as the trunk.
+
+> The revision number is only useful in the context of the branch, so it
+> only matters when comparing versions within a branch. When you switch
+> between branches, if you're interested in the revision number you'll
+> still need to know which branch you're talking about.
+
+I think this is our main disagreement.  I see all the branches as part
+of the same codebase, with monotonically increasing timestamp patch
+numbers.  If you were to collapse all the commit snapshots down into a
+single chronological "virtual branch", it would still make sense, it
+would just be a bit unorganized.  We do all try to move in the same
+general direction ;).
+
+> Switching between branches doesn't change the canonical version string.
+
+Different released code should have different version numbers.
+
+> > For example, when I upgraded to rich root to pull Ben's patch, I'm not
+> > sure if Chris upgraded the trunk and merged my branch, or just ditched
+> > the trunk and cloned my branch. Using actual bzr revision numbers
+> > would make switching branches that either wrong (in the case of rev-id
+> > decreases) or confusing (in the case of a single non-consecutive
+> > increase).
+> 
+> This, then, is an argument for not having the revision number in the
+> version string at all. The version then becomes a more traditional
+> “major.minor.patch” tuple, and is only ever updated when some release
+> manager of the canonical branch decides it's correct to do so.
+
+It is an argument for not using the revision number.  You can avoid
+revision numbers by using hand-coded patch numbers, or by using
+timestamps, which is what we're trying to decide on :p.
+
+> If we use the ‘bzr version-info --format=python > foo_version.py’
+> command in some build routine, the branch's revision number will be
+> available directly within Python by importing that module. That would
+> allow it to be output in some UI, if that's what you're interested in
+> seeing.
+
+True.  Which means that whichever version string wins out, the other
+side will still be able to access the info we both want included ;).
+We can certainly suggest that bug reporters submit their
+  be --verbose-version
+when they submit bugs.  The only role of the official "version string"
+is to make life easy for packagers.  If they woln't be switching
+branches, then either of our proposals are fine.  If they will, then
+I think timestamps work better.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt