diff options
Diffstat (limited to '.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments')
48 files changed, 1553 insertions, 0 deletions
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body new file mode 100644 index 0000000..fa9e963 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body @@ -0,0 +1,36 @@ +* W. Trevor King (wking@drexel.edu) wrote: +> One problem is that we don't actually have "releases". People just +> clone a branch, install, and go. + + This is actually the main reason I've manually mirrored the tree in +the past, so that users of our projects can get BE. If tarballs were +available I probably wouldn't even bother, but bzr really isn't a nice +dependency for just submitting/commenting on bugs. + + Isn't there a bzr web interface that at least supports creating +tarballs/zips? It is pretty standard functionality for most other VCS' +web interfaces so I'm guessing there must be, but loggerhead seems not +to support it. + + If it is a case of not having the hardware to host a more featureful +web UI I may be able to offer some assistance. + +> If you're worried about stability, just clone from a more stable branch +> (i.e., Chris' trunk). I think > this is good for distributed development, +> but maybe makes it hard to package into a conventional release-based system. +> With the bzr patch number in setup.py as the patch release number, I would be +> releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at +> about the same point. I would rather be releasing my +> 0.1.20090714121347 +> while Chris releases his +> 0.1.20090713154540 +> Since then the similarity is clearer. + + Both approaches seem pretty odd to me, as a user you would have no +idea if 0.1.200910302359 has the fixes you required in a release you +were using that was numbered 0.1.200907141554. Surely you'd at least be +{pre,suf}fixing a branch name to the version. + +Thanks, + +James diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values new file mode 100644 index 0000000..e7077e7 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values @@ -0,0 +1,14 @@ +Alt-id: <20090714142942.GA5717@ukfsn.org> + + +Author: James Rowe <jnrowe@gmail.com> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 15:29:42 +0100 + + +In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body new file mode 100644 index 0000000..8c890f3 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body @@ -0,0 +1,27 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> On Tue, Nov 17, 2009 at 01:41:26PM -0300, Nicolas Alvarez wrote: +> > I'm using the latest version available on Debian +> > (0.0.193+bzr.r217-2). I should ask for an updated package... +> +[…] + +> There is also an outstanding Debian bug for updating the Debian package +> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544515 +> so there may be a more current package on the way, but I don't know +> about timeframes for that sort of thing. + +It would make it much easier on the Debian package maintainer if the +Bugs Everywhere project would make conventional tarball releases, with +conventional version numbers, with a changelog describing what has +changed between versions. + +Trying to maintain a package of a project that is only made available by +undifferentiated VCS revision numbers is a lot more effort, and so +doesn't happen very often. + +-- + \ “Roll dice!” “Why?” “Shut up! I don't need your fucking | + `\ *input*, I need you to roll dice!” —Luke Crane, demonstrating | +_o__) his refined approach to play testing, 2009 | +Ben Finney diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values new file mode 100644 index 0000000..3b45fbf --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values @@ -0,0 +1,11 @@ +Alt-id: <87d43gn8ju.fsf_-_@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Wed, 18 Nov 2009 13:30:29 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body new file mode 100644 index 0000000..7e1434b --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body @@ -0,0 +1,115 @@ +On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote: +> * W. Trevor King (wking@drexel.edu) wrote: +> > One problem is that we don't actually have "releases". People just +> > clone a branch, install, and go. +> +> This is actually the main reason I've manually mirrored the tree in +> the past, so that users of our projects can get BE. If tarballs were +> available I probably wouldn't even bother, but bzr really isn't a nice +> dependency for just submitting/commenting on bugs. + +Fair enough. It will be good when we get a commit-able web interface +and/or email interface going. + +> Isn't there a bzr web interface that at least supports creating +> tarballs/zips? It is pretty standard functionality for most other VCS' +> web interfaces so I'm guessing there must be, but loggerhead seems not +> to support it. + +Unfortunately, people would still need bzr to install the versioned source: + + libbe/_version.py: + bzr version-info --format python > $@ + +So you'll need a "release" target in the makefile to build a bzr-less +install. While you're at it, you should probably compile the manpage +too to remove the docbook-to-man dependency. + +Do people want a HEAD tarball too? There must be a bzr equivalent of + .git/hooks/post-update +but I don't know what it is. + +> > If you're worried about stability, just clone from a more stable branch +> > (i.e., Chris' trunk). I think > this is good for distributed development, +> > but maybe makes it hard to package into a conventional release-based system. +> > With the bzr patch number in setup.py as the patch release number, I would be +> > releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at +> > about the same point. I would rather be releasing my +> > 0.1.20090714121347 +> > while Chris releases his +> > 0.1.20090713154540 +> > Since then the similarity is clearer. +> +> Both approaches seem pretty odd to me, as a user you would have no +> idea if 0.1.200910302359 has the fixes you required in a release you +> were using that was numbered 0.1.200907141554. Surely you'd at least be +> {pre,suf}fixing a branch name to the version. + +"be --version" currently gives you the revision id: + wking@drexel.edu-20090714121347-c6rloikst1t3m5yl +which tells you exactly which commit your installed version is based on. +If we want stick with revision numbers, how about: + major.minor.revno-branch_nick +But then we'd have to pick "unique" branch nicknames... + +I'd sliced out the timestamp portion of the revision id so that the +"patch-number" would be an integer and the branch name wasn't +references, so that "upgrading" from one branch to another could be +transparent to the users (who just see an increading timestamp), but +still available to the developers (who know when commits were made to +the branches they track, and the likelyhood of to-the-second commit +collisions in official packages is small). + +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 changelog. +> > +> > Which we don't bother keeping (also NEWS), since "bzr log" works so +> > nicely. +> +> That's not a changelog, that's a commit log of every source-level commit +> made. Far too much detail for a changelog of *user-visible* changes +> associated with a release. + +I need a user around to help me determine "user-visable" changes ;). +My labmates loose interest after be init/new/comment :p. None of +which has ever changed, other than set-root -> init ;). + +> > The timestamp should at least replace the patch release number, which +> > you agree is-desirable-to increase motonically ;). +> +> I still disagree that a timestamp is the right thing to use there. 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. 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). + +On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote: +> > I agree that's a problem. I think the solution is to start making +> > releases, with specific version strings, as source tarballs. +> +> I'm happy to do this if people think it would be useful, and I don't +> yet have a strong opinion on whether the releases should come with +> version numbers or timestamps. + +I imagine the news from 2006 to now will be somewhat abridged ;). + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values new file mode 100644 index 0000000..9e84a24 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values @@ -0,0 +1,14 @@ +Alt-id: <20090714171725.GB10445@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 13:17:25 -0400 + + +In-reply-to: 0c40c13a-3515-4b45-a8c3-142cceab9254 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body new file mode 100644 index 0000000..a0b6a14 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body @@ -0,0 +1,58 @@ +Chris Ball <cjb@laptop.org> writes: + +> Hi, +> +> > That's not a changelog, that's a commit log of every source-level +> > commit made. Far too much detail for a changelog of +> > *user-visible* changes associated with a release. +> +> I think I agree with both of you. :) It seems like it's both true that +> there's no point in keeping a GNU-style ChangeLog these days + +I think I have a better understanding of why this apparent disagreement +occurred, and it was due to my sloppy use of terms. + +Looking into it further, it seems there is a certain expectation (set, +in part, by the long-standing GNU coding conventions) that a “GNU-style +ChangeLog” contains not only a particular *format*, but information at +a particular level of *detail*. + +That is, a GNU ChangeLog is intended for the style of work where one +logs all the changes made to every file in the tree each working day, +and then makes a new day's entry above that, and so on. This is, of +course, entirely redundant with a VCS revision history, which makes all +the commit messages available on request. + +So to disambiguate, that's not what I meant. I'm more familiar with a +less-frequently-updated and less-fine-detail change log; perhaps more +akin to the GNU-style “NEWS” file. + +> and that if we make a release we should write an announce mail that +> directly mentions new user-visible changes as well as attaching the +> commit log. That smaller list of highly user-visible changes could +> live in NEWS, or in the announce mail, or both. + +Yes, that's mostly what I meant. + +I actually don't think the commit log needs to be part of the release at +all. It's of interest only to those who want fine-level detail about +changes to every file, and for that purpose I think read access to the +VCS is much better. Packaging a static copy of the commit log as plain +text seems pointless. + +Rather, we should treat a user-changes level “NEWS” file (or whatever +name we choose for it) as part of the documentation, and set the +expectation among the team that it will be updated for each user-visible +change being worked on, like any other documentation. + +-- + \ “… Nature … is seen to do all things Herself and through | + `\ herself of own accord, rid of all gods.” —Titus Lucretius | +_o__) Carus, c. 40 BCE | +Ben Finney + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values new file mode 100644 index 0000000..320c484 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values @@ -0,0 +1,14 @@ +Alt-id: <87hbxdhtkp.fsf@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Thu, 16 Jul 2009 19:21:10 +1000 + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body new file mode 100644 index 0000000..5f478b5 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body @@ -0,0 +1,96 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +W. Trevor King wrote: +> Thinking about this some more, I think that the role of the +> main-branch is to officially sanction the current state of the code as +> "released". If a series of commits will leave a branch in a +> known-unusable form, they should be carried out in some appropriately +> named development branch. Then the log of commits to the main branch +> ("bzr log -n 1" for bzr > ) should produce a fairly respectable +> changelog. + +This is how we develop bzr itself. The mainline is controlled by PQM, +which is a tool that merges feature branches, runs the tests, and +commits only if the tests pass. + +$ bzr log --short --limit 10 + 4534 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (abentley) Implement merge --interactive + + 4533 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (jml) Merge in changes from 1.17 branch. + + 4532 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (igc) zc.buildout Windows build support (Sidnei da Silva) + + 4531 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (vila) Delete forgotten debug print + + 4530 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (vila) Isolate some tests from TZ + + 4529 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (igc) Bazaar 2.0 Upgrade Guide + + 4528 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (mbp) correction to news + + 4527 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (jml) Merge in 1.17 branch, updating version numbers and NEWS file. + + 4526 Canonical.com Patch Queue Manager 2009-07-10 [merge] + (mbp, vila) Finish the *_implementation to per_* test renaming + + 4525 Canonical.com Patch Queue Manager 2009-07-10 [merge] + (vila) Quicker check for changes in mutable trees + +You can also see all the merges as they come into the mainline: + +$ bzr log --short --limit 10 --include-merges + 4534 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (abentley) Implement merge --interactive + + 4526.6.15 Aaron Bentley 2009-07-14 + Update command help + + 4526.6.14 Aaron Bentley 2009-07-14 + Use default DiffWriter. + + 4526.6.13 Aaron Bentley 2009-07-14 + Add docstring to do_interactive. + + 4526.6.12 Aaron Bentley 2009-07-14 + Updates from review. + + 4526.6.11 Aaron Bentley 2009-07-13 + Update NEWS. + + 4526.6.10 Aaron Bentley 2009-07-13 [merge] + Merged apply-vocab into merge-interactive. + + 4526.7.4 Aaron Bentley 2009-07-13 [merge] + Merged bzr.dev into apply-vocab. + + 4526.6.9 Aaron Bentley 2009-07-13 [merge] + Merged apply-vocab into merge-interactive. + + 4526.7.3 Aaron Bentley 2009-07-13 + Test shelve_change. + +> This also means that _every_commit_ to a main branch would +> be an official release. + +We don't do that. We have official releases every 4 weeks, but we do +believe that running bzr.dev is pretty safe, because it's always tested +and our test suite is quite thorough. + +Aaron +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.9 (GNU/Linux) +Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org + +iEYEARECAAYFAkpcznIACgkQ0F+nu1YWqI0yhACePTFUUp6u+Dw+8IRwWOWBQRtb +TgsAniJq4lqnDfjNACMr7IEt7xYJhx7m +=BbGG +-----END PGP SIGNATURE----- diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values new file mode 100644 index 0000000..8cfe1b0 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values @@ -0,0 +1,14 @@ +Alt-id: <4A5CCE76.9040106@aaronbentley.com> + + +Author: Aaron Bentley <aaron@aaronbentley.com> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 14:29:10 -0400 + + +In-reply-to: ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body new file mode 100644 index 0000000..b34e037 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body @@ -0,0 +1,52 @@ +On Tue, Jul 14, 2009 at 07:34:04PM +0100, jnrowe@gmail.com wrote: +> [This time to the list] +> +> * W. Trevor King (wking@drexel.edu) wrote: +> > On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote: +> > > Isn't there a bzr web interface that at least supports creating +> > > tarballs/zips? It is pretty standard functionality for most other VCS' +> > > web interfaces so I'm guessing there must be, but loggerhead seems not +> > > to support it. +> > +> > Unfortunately, people would still need bzr to install the versioned source: +> > +> > libbe/_version.py: +> > bzr version-info --format python > $@ +> +> I hadn't even seen that change go in. The last upstream change in the +> version I have installed locally was by you on 2008-11-24. + +It's only been in Chris' http://bzr.bugseverywhere.org/be/ branch +since revno: 321, 2009-06-25. Obviously we may have to adjust the +--verison output once we settle on a versioning scheme, but whatever +we pick, I think having the auto-generated libbe/_version.py around +for pinpointing bugs is worth the trouble of requiring bzr when +building distribution tarballs. + +> > So you'll need a "release" target in the makefile to build a bzr-less +> > install. While you're at it, you should probably compile the manpage +> > too to remove the docbook-to-man dependency. +> +> Maybe for others. Our packages just don't have the manpage as it is only +> the "be help" text reformatted, the easy option is sometimes the right +> one :) Also, I've just noticed that it has even less documentation in +> the bzr tree[1] making its installation much less compelling unless your +> packaging rules require a man page like Debians. +> +> Out of curiosity why is the Makefile being used for this stuff anyway? +> It is going to make it difficult to build locally when we finally get +> around to merging. Examples: If distutils was being used exclusively it +> would fix the #! lines in xml/*. We'd be able to point Python +> $version_of_the_day at setup.py instead of having to sed the Makefile or +> run setup and manually install other files. + +I speak Makefile better than I speak distutils ;). I'm not sure how +to translate the be.1 generation/installation or the libbe/_version.py +generation into distutils. Anyone else? + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values new file mode 100644 index 0000000..e0c0955 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values @@ -0,0 +1,14 @@ +Alt-id: <20090714191145.GB10606@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 15:11:45 -0400 + + +In-reply-to: 6e315abe-a080-4369-8729-4aea2dee8494 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body new file mode 100644 index 0000000..4ebb4f2 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body @@ -0,0 +1,51 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> ** NEWS file + +Speaking as the package maintainer, I would like a ‘ChangeLog’ file +separate from a ‘NEWS’ file. + +The ‘NEWS’ file would continue to be hand-edited, and would be a +high-level view of user-visible changes in the project each version. +Users could reasonably expect to be interested in this file when +installing a new version. It would also make sense to retire old news +From this file once it becomes sufficiently old, to keep it relevant to +users to read. + + +The ‘ChangeLog’ would be an automatically-generated changelog of +low-level changes, not for general human consumption but for letting +recipients have a fighting chance at knowing the historical context of a +particular change without access to the VCS. It would probably be best +done as Trevor says: + +> Depending on our level of masochism, either something starting out +> along the lines of [2] +> bzr log --gnu-changelog -n1 -r 200.. + +That makes it necessary to add the changelog file to the tarball, since +it won't be a file tracked by VCS and therefore won't be exported. Not a +problem:: + + $ release_version="1.0.0" + $ release_name="be-$release_version" + $ tarball_file=../$release_name.tar.gz + $ work_dir=$(mktemp -t -d) + $ export_dir=$work_dir/$release_name + $ changelog_file=$export_dir/ChangeLog + + $ bzr export $export_dir + $ bzr log --gnu-changelog -n1 -r ..tag:"$release_version" > $changelog_file + $ tar -czf $tarball_file $export_dir + $ rm -r $work_dir/ + + $ ls $tarball_file + ../be-1.0.0.tar.gz + $ tar -tzf $tarball_file | grep ChangeLog + be-1.0.0/ChangeLog + +-- + \ “I bought a dog the other day. I named him Stay. It's fun to | + `\ call him. ‘Come here, Stay! Come here, Stay!’ He went insane. | +_o__) Now he just ignores me and keeps typing.” —Steven Wright | +Ben Finney diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values new file mode 100644 index 0000000..b45a747 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values @@ -0,0 +1,14 @@ +Alt-id: <873a4cmjw5.fsf@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Wed, 18 Nov 2009 22:23:06 +0000 + + +In-reply-to: a4720227-43cf-49aa-8f9f-f49f46e3e809 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body new file mode 100644 index 0000000..7ffe231 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body @@ -0,0 +1,38 @@ +[This time to the list] + +* W. Trevor King (wking@drexel.edu) wrote: +> On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote: +> > Isn't there a bzr web interface that at least supports creating +> > tarballs/zips? It is pretty standard functionality for most other VCS' +> > web interfaces so I'm guessing there must be, but loggerhead seems not +> > to support it. +> +> Unfortunately, people would still need bzr to install the versioned source: +> +> libbe/_version.py: +> bzr version-info --format python > $@ + + I hadn't even seen that change go in. The last upstream change in the +version I have installed locally was by you on 2008-11-24. + +> So you'll need a "release" target in the makefile to build a bzr-less +> install. While you're at it, you should probably compile the manpage +> too to remove the docbook-to-man dependency. + + Maybe for others. Our packages just don't have the manpage as it is only +the "be help" text reformatted, the easy option is sometimes the right +one :) Also, I've just noticed that it has even less documentation in +the bzr tree[1] making its installation much less compelling unless your +packaging rules require a man page like Debians. + + Out of curiosity why is the Makefile being used for this stuff anyway? +It is going to make it difficult to build locally when we finally get +around to merging. Examples: If distutils was being used exclusively it +would fix the #! lines in xml/*. We'd be able to point Python +$version_of_the_day at setup.py instead of having to sed the Makefile or +run setup and manually install other files. + +Thanks, + +James + 1. http://pullcord.laptop.org:4000/revision/314.1.15/doc/be.1.sgml diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values new file mode 100644 index 0000000..4f1d60d --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values @@ -0,0 +1,14 @@ +Alt-id: <20090714183404.GB26032@ukfsn.org> + + +Author: jnrowe@gmail.com + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 19:34:04 +0100 + + +In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body new file mode 100644 index 0000000..d00eb64 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body @@ -0,0 +1,22 @@ +Hi, + + > It would make it much easier on the Debian package maintainer if + > the Bugs Everywhere project would make conventional tarball + > releases, with conventional version numbers, with a changelog + > describing what has changed between versions. + +Fair point. + +How do people feel about pushing for a 1.0 release, with Trevor's tree +plus a finished cfbe merge? Or would we rather wait until afterwards +to try for cfbe? + +- Chris. +-- +Chris Ball <cjb@laptop.org> +One Laptop Per Child + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values new file mode 100644 index 0000000..4fb068d --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values @@ -0,0 +1,14 @@ +Alt-id: <m3ocn09310.fsf@pullcord.laptop.org> + + +Author: Chris Ball <cjb@laptop.org> + + +Content-type: text/plain + + +Date: Tue, 17 Nov 2009 22:53:31 +0000 + + +In-reply-to: 1847f1f8-525a-42c4-ae2b-e9377459d2a6 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body new file mode 100644 index 0000000..24ff7b0 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body @@ -0,0 +1,58 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> Currently setup.py sets the version number for BE to 0.0.193 and the +> url to http://panoramicfeedback.com/opensource/. These are both a bit +> outdated ;). + +Right, that should change. + +> I've switched my branch over to the current url, and moved to +> last-commit-timestamp version numbers. + +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 changelog. + +> This removes the "prefered branch" issues with the old scheme, and +> version numbers should increase monotonically + +The English word “should” is ambiguous in this context. Are you saying +this is desirable, or are you predicting that it will likely be the +case? + +I don't see how it's either, so am doubly confused :-) + +> but it looses any stability information suggested by the preceding +> 0.0. + +The convention for three-part version strings is often: + + * Major release number (big changes in how the program works, + increasing monotonically per major release, with “0”indicating no + major release yet) + + * Minor release number (smaller impact on how the program works, + increasing monotonically per minor release, with “0” indicating no + minor release yet since the previous major) + + * Patch release number (bug-fix and other changes that don't affect + the documented interface, increasing monotonically per patch + release, with “0” indicating no patch release since the previous + major or minor) + +Obviously there's no standard or enforcement for this, but that's the +interpretation I usually give to dotted version strings in the absence +of more formal declaration specific to the project. + +> We can add those back in if people want. Does the first 0 mean +> "interfaces in flux" and the second 0 mean "lots of bugs"? If so, I +> think we're up to 0.1, since the major features are pretty calm. + +I disagree with your interpretation and prefer mine, above; on that +basis, I agree that we're at least up to version 0.1 by now :-) + +-- + \ “A lot of water has been passed under the bridge since this | + `\ variation has been played.” chess book, Russia | +_o__) | +Ben Finney diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values new file mode 100644 index 0000000..c5d9cbb --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values @@ -0,0 +1,14 @@ +Alt-id: <87ocrnjvat.fsf@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 22:36:26 +1000 + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body new file mode 100644 index 0000000..a3fc57f --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body @@ -0,0 +1,36 @@ +I've written up a little release script that bundles all the steps +we've mentioned so far into a single command. Of course, we'll still +have to keep NEWS up to date on our own. + +The output prints a trace of what's going on: + + $ ./release.py 1.0.0 + set libbe.version._VERSION = '1.0.0' + updating AUTHORS + updating ./becommands/assign.py + updating ./becommands/html.py + ... + commit current status: Bumped to version 1.0.0 + tag current revision 1.0.0 + export current revision to be-1.0.0 + generate libbe/_version.py + copy libbe/_version.py to be-1.0.0/libbe/_version.py + generate ChangeLog file be-1.0.0/ChangeLog up to tag 1.0.0 + set vcs_name in be-1.0.0/.be/settings to None + create tarball be-1.0.0.tar.gz + remove be-1.0.0 + +Since we'll be distributing a non-bzr-repo version, it would be nice +to adapt our 'submit bug' procedure (outlined on the main page) to one +that works with this setup. Without guaranteed versioning, that would +probably be something along the lines of + be email-bugs [--to be-devel@bugseverywhere.org] BUG-ID ... +With interfaces/email/interactive listening on the recieving end to +grab new-bug emails and import them into an incoming bug repository. + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values new file mode 100644 index 0000000..b6d25cb --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values @@ -0,0 +1,14 @@ +Alt-id: <20091120132219.GA17577@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Fri, 20 Nov 2009 13:22:19 +0000 + + +In-reply-to: 49e0425b-3332-4d0e-b371-300eccd55370 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body new file mode 100644 index 0000000..5d29f85 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body @@ -0,0 +1,102 @@ +On Tue, Nov 17, 2009 at 05:53:31PM -0500, Chris Ball wrote: +> > It would make it much easier on the Debian package maintainer if +> > the Bugs Everywhere project would make conventional tarball +> > releases, with conventional version numbers, with a changelog +> > describing what has changed between versions. +> How do people feel about pushing for a 1.0 release, with Trevor's tree +> plus a finished cfbe merge? Or would we rather wait until afterwards +> to try for cfbe? + +Sounds good to me. Not that my tree is much ahead of the trunk at the +moment. We've talked over most of these issues a few times, so I'll +just summarize where I think we stand on the steps needed to make a +release. + +** cfbe integration + +Postpone until we work out bzr/hg versioning [1]? + +** Conventional version number + +Set to "1.0.0" using libbe.version._VERSION. + +** NEWS file + +Depending on our level of masochism, either something starting out +along the lines of [2] + bzr log --gnu-changelog -n1 -r 200.. +(commit 200, or + aaron.bentley@utoronto.ca-20060411035623-9b8d222282a26ce1 + was the last time anyone touched the NEWS file), +or a much abbreviated entry [3,4], along the lines of my current NEWS +file (changed just a few minutes ago). + +** Tag bzr commit + + bzr tag 1.0.0 + +** Create tarball + +From Ben[5]: + bzr export /tmp/be-1.0.0.tar.gz + + +References: + +[1] +On Thu, Jul 23, 2009 at 05:38:03PM -0400, Steve Losh wrote: +> On Jul 21, 2009, at 9:59 AM, W. Trevor King wrote: +> > Steve's also versioning it with Mercurial. Will he mind changing to +> > Bazaar? +> +> Yeah, I've tried bazaar but really don't like the interface at all. If +> everyone else really wants me to move it over I guess I can though. + +[2] +On Tue, Jul 14, 2009 at 11:05:38AM -0400, Chris Ball wrote: +> Actually, there's a `bzr log --gnu-changelog` now, and `bzr help +> log-formats` offers some more styles. (None of them seem to match +> my preferred style for release announcements exactly, which would +> be `git shortlog`-style.) + +[3] +On Thu, Jul 16, 2009 at 07:21:10PM +1000, Ben Finney wrote: +> I actually don't think the commit log needs to be part of the release at +> all. It's of interest only to those who want fine-level detail about +> changes to every file, and for that purpose I think read access to the +> VCS is much better. Packaging a static copy of the commit log as plain +> text seems pointless. +> +> Rather, we should treat a user-changes level “NEWS” file (or whatever +> name we choose for it) as part of the documentation, and set the +> expectation among the team that it will be updated for each user-visible +> change being worked on, like any other documentation. + +[4] +On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote: +> Hi, +> +> > That's not a changelog, that's a commit log of every source-level +> > commit made. Far too much detail for a changelog of +> > *user-visible* changes associated with a release. +> +> I think I agree with both of you. :) It seems like it's both true that +> there's no point in keeping a GNU-style ChangeLog these days, and that +> if we make a release we should write an announce mail that directly +> mentions new user-visible changes as well as attaching the commit log. +> That smaller list of highly user-visible changes could live in NEWS, +> or in the announce mail, or both. + +[5] +On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> Even better: ‘bzr export /tmp/foo.tar.gz’ will create a source tarball +> of all the files in the branch's VCS inventory. All we need to do is +> start the practice of tagging a release in the VCS, and export the +> tarball at that time. + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values new file mode 100644 index 0000000..7f205d6 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values @@ -0,0 +1,14 @@ +Alt-id: <20091118011403.GB9503@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Wed, 18 Nov 2009 01:14:03 +0000 + + +In-reply-to: 72a519e3-3d6b-4f0f-b412-1310efd255eb + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body new file mode 100644 index 0000000..8b32751 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body @@ -0,0 +1,14 @@ +Hi, + + > Which we don't bother keeping (also NEWS), since "bzr log" works + > so nicely. If you really want an standard changelog, see + > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html + +Actually, there's a `bzr log --gnu-changelog` now, and `bzr help +log-formats` offers some more styles. (None of them seem to match +my preferred style for release announcements exactly, which would +be `git shortlog`-style.) + +- Chris. +-- +Chris Ball <cjb@laptop.org> diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values new file mode 100644 index 0000000..239feb5 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values @@ -0,0 +1,14 @@ +Alt-id: <m3ljmrfgot.fsf@pullcord.laptop.org> + + +Author: Chris Ball <cjb@laptop.org> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 11:05:38 -0400 + + +In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body new file mode 100644 index 0000000..33a8d66 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body @@ -0,0 +1,51 @@ +I don't think anyone's changing their mind ;), so tallying the +comments so far: + +On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> I still disagree that a timestamp is the right thing to use there. 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. + ++1 for trunk version number. + +On Tue, Jul 14, 2009 at 05:27:52PM +0200, Elena of Valhalla wrote: +> I also have a weak preference for version numbers, as long as they +> give useful informations on the state the release. + ++1 for trunk version number. + +On Tue, Jul 14, 2009 at 02:29:10PM -0400, Aaron Bentley wrote: +> We don't do that. We have official releases every 4 weeks, but we do +> believe that running bzr.dev is pretty safe, because it's always tested +> and our test suite is quite thorough. + ++1 for by hand version bumps. + +On Fri, Jul 17, 2009 at 11:37:49PM +0200, Gianluca Montecchi wrote: +> The version number of trunk _is_ should be the official version number of the +> Bugs Everywhere releases. +> The version number in branch does not means nothing outside the branch. +> At least we can have a mechanism to build a version number scheme that is +> consistent for us to be able to merge branch easily. + ++1 for trunk version number. + +And me with my timestamps ;). + +Sounds like we should go with trunk version number, but that it should +be set by hand whenever Chris decides to release something, since the +rest of us don't know what version the trunk is on. Unless we do +something like: + bzr log -n 0 | grep -B2 'nick: be$' | head -n1 | sed 's/ *revno: \([0-9]*\).*/\1/' +to extract the last trunk commit referenced from our branch. + +Implementation preferences? (i.e. Chris vs. regexp matching :p) + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values new file mode 100644 index 0000000..b757933 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values @@ -0,0 +1,14 @@ +Alt-id: <20090718105008.GA31639@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 06:50:08 -0400 + + +In-reply-to: c35835c0-8f9f-4090-ba92-1f616867e486 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body new file mode 100644 index 0000000..063afcb --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body @@ -0,0 +1,30 @@ +Hi, + + > That's not a changelog, that's a commit log of every source-level + > commit made. Far too much detail for a changelog of + > *user-visible* changes associated with a release. + +I think I agree with both of you. :) It seems like it's both true that +there's no point in keeping a GNU-style ChangeLog these days, and that +if we make a release we should write an announce mail that directly +mentions new user-visible changes as well as attaching the commit log. +That smaller list of highly user-visible changes could live in NEWS, +or in the announce mail, or both. + + > I agree that's a problem. I think the solution is to start making + > releases, with specific version strings, as source tarballs. + +I'm happy to do this if people think it would be useful, and I don't +yet have a strong opinion on whether the releases should come with +version numbers or timestamps. + +Thanks, + +- Chris. +-- +Chris Ball <cjb@laptop.org> + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values new file mode 100644 index 0000000..466be33 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values @@ -0,0 +1,14 @@ +Alt-id: <m3k52bfgf0.fsf@pullcord.laptop.org> + + +Author: Chris Ball <cjb@laptop.org> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 11:11:31 -0400 + + +In-reply-to: ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body new file mode 100644 index 0000000..1e2a870 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body @@ -0,0 +1,37 @@ +On Tue, Jul 14, 2009 at 01:17:25PM -0400, W. Trevor King wrote: +> 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 changelog. +> > > +> > > Which we don't bother keeping (also NEWS), since "bzr log" works so +> > > nicely. +> > +> > That's not a changelog, that's a commit log of every source-level commit +> > made. Far too much detail for a changelog of *user-visible* changes +> > associated with a release. +> +> I need a user around to help me determine "user-visable" changes ;). +> My labmates loose interest after be init/new/comment :p. None of +> which has ever changed, other than set-root -> init ;). + +Thinking about this some more, I think that the role of the +main-branch is to officially sanction the current state of the code as +"released". If a series of commits will leave a branch in a +known-unusable form, they should be carried out in some appropriately +named development branch. Then the log of commits to the main branch +("bzr log -n 1" for bzr > ) should produce a fairly respectable +changelog. Obviously we are all quite guilty of doing most of our +development in single branches, but it may be a useful model going +forward. This also means that _every_commit_ to a main branch would +be an official release. + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values new file mode 100644 index 0000000..b5c41c9 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values @@ -0,0 +1,14 @@ +Alt-id: <20090714182034.GA10606@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 14:20:34 -0400 + + +In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body new file mode 100644 index 0000000..e02bd38 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body @@ -0,0 +1,25 @@ +On Tue, Jul 14, 2009 at 5:11 PM, Chris Ball<cjb@laptop.org> wrote: +> > I agree that's a problem. I think the solution is to start making +> > releases, with specific version strings, as source tarballs. +> +> I'm happy to do this if people think it would be useful, and I don't +> yet have a strong opinion on whether the releases should come with +> version numbers or timestamps. + +as an user of be that plans to try and "package" it for openembedded, +a release would be very useful: writing a recipe that downloads a +specific commit from bzr and builds it is probably feasible, but +definitely not ideal. + +I also have a weak preference for version numbers, as long as they +give useful informations on the state the release. + +-- +Elena ``of Valhalla'' + +email: elena.valhalla@gmail.com + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values new file mode 100644 index 0000000..57b408f --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values @@ -0,0 +1,14 @@ +Alt-id: <5c5e5c350907140827u218553e8rc5773325d43c2bf2@mail.gmail.com> + + +Author: Elena of Valhalla <elena.valhalla@gmail.com> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 17:27:52 +0200 + + +In-reply-to: aad59898-8949-44fb-ad0b-2acea6eb2ef8 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body new file mode 100644 index 0000000..d8014d2 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body @@ -0,0 +1,102 @@ +On Thursday 16 July 2009 12:38:55 W. Trevor King wrote: +> 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. + +But if we have a canonical "main branch" that we release, and the packager +get, we can refer to it as the stable branch, that it is not a bad idea. + + + +> > 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 version number of trunk _is_ should be the official version number of the +Bugs Everywhere releases. +The version number in branch does not means nothing outside the branch. +At least we can have a mechanism to build a version number scheme that is +consistent for us to be able to merge branch easily. + +> > 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 ;). + +I don't think that, outside the developers, a version number like + +cjb@laptop.org-20090713154540-ve4pmydqzb1ghgvc + +is a good choice, not for the user of BE, not for the packager of BE + + +> > 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. + +We can use both. +During the development we can use version number like + +x.y.z.timestamp + +As we decide to release a stable version, the release manager set the version +number to a more traditional x.y.z format, and create a branch (stable branch) + +This way we have these advantages: + +1) an user have a simple version number to use for bug report/feature +request/help request + +2) a packager have an easy life to choose to package a stable or a trunk +version, knowing what are they doing + +bonus) we can maintain a stable and a developmente source tree/branch, where +in the development tree we can make also backward incompatible modification to +the source without making any damage to the users/packagers, while in the +stable branch we can make only bugfix/security fix or port from the devel branch +some interesting features as long as they don't break compatibility. + +bye +Gianluca + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values new file mode 100644 index 0000000..c7c0273 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values @@ -0,0 +1,14 @@ +Alt-id: <200907172337.49779.gian@grys.it> + + +Author: Gianluca Montecchi <gian@grys.it> + + +Content-type: text/plain + + +Date: Fri, 17 Jul 2009 23:37:49 +0200 + + +In-reply-to: f925e56f-26f9-4620-82fb-a0f160f27921 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body new file mode 100644 index 0000000..4e8445a --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body @@ -0,0 +1,18 @@ +Currently setup.py sets the version number for BE to 0.0.193 and the +url to http://panoramicfeedback.com/opensource/. These are both a bit +outdated ;). I've switched my branch over to the current url, and +moved to last-commit-timestamp version numbers. This removes the +"prefered branch" issues with the old scheme, and version numbers +should increase monotonically, but it looses any stability information +suggested by the preceding 0.0. + +We can add those back in if people want. Does the first 0 mean +"interfaces in flux" and the second 0 mean "lots of bugs"? If so, I +think we're up to 0.1, since the major features are pretty calm. + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values new file mode 100644 index 0000000..00309a2 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values @@ -0,0 +1,11 @@ +Alt-id: <20090714110543.GB4855@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 07:05:43 -0400 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body new file mode 100644 index 0000000..fce4941 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body @@ -0,0 +1,72 @@ +On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> "W. Trevor King" <wking@drexel.edu> writes: +> > I've switched my branch over to the current url, and moved to +> > last-commit-timestamp version numbers. +> +> 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 changelog. + +Which we don't bother keeping (also NEWS), since "bzr log" works so nicely. +If you really want an standard changelog, see + http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html + +> > This removes the "prefered branch" issues with the old scheme, and +> > version numbers should increase monotonically +> +> The English word “should” is ambiguous in this context. Are you saying +> this is desirable, or are you predicting that it will likely be the +> case? + +Both. + +> I don't see how it's either, so am doubly confused :-) + +The timestamp should at least replace the patch release number, which +you agree is-desirable-to increase motonically ;). I also predict +that it will increase monotonically for any given branch, since the +branch HEAD will have both the most recent commit and the highest +version number. The only problem I can think of is having your clock +_way_ off, and that is unlikely enough to ignore. If you hop between +branches, the timestamp is much more likely to increase going to the +more modern branch than the bzr revision number, which desynchronize +between branches fairly quickly. + +> The convention for three-part version strings is often: +> +> * Major release number (big changes in how the program works, +> increasing monotonically per major release, with “0”indicating no +> major release yet) +> +> * Minor release number (smaller impact on how the program works, +> increasing monotonically per minor release, with “0” indicating no +> minor release yet since the previous major) +> +> * Patch release number (bug-fix and other changes that don't affect +> the documented interface, increasing monotonically per patch +> release, with “0” indicating no patch release since the previous +> major or minor) + +One problem is that we don't actually have "releases". People just +clone a branch, install, and go. If you're worried about stability, +just clone from a more stable branch (i.e., Chris' trunk). I think +this is good for distributed development, but maybe makes it hard to +package into a conventional release-based system. With the bzr patch +number in setup.py as the patch release number, I would be releasing +my 0.1.363 while Chris releases his 0.1.314, even though they're at +about the same point. I would rather be releasing my + 0.1.20090714121347 +while Chris releases his + 0.1.20090713154540 +Since then the similarity is clearer. + +At any rate, I think the two approaches are close enough that an +auto-updating timestamp beats a manually bumped patch number, since +no-one ever actually bumps the patch number ;). + +-- +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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values new file mode 100644 index 0000000..a3f74c4 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values @@ -0,0 +1,14 @@ +Alt-id: <20090714133732.GB6160@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 09:37:32 -0400 + + +In-reply-to: 744435b7-1521-4059-a55d-f0c403d7b4d8 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body new file mode 100644 index 0000000..5eeb353 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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 diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values new file mode 100644 index 0000000..63a2cae --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values @@ -0,0 +1,14 @@ +Alt-id: <20090716103855.GA8579@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Thu, 16 Jul 2009 06:38:55 -0400 + + +In-reply-to: fdb615a4-168a-467b-8090-875c998455e5 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body new file mode 100644 index 0000000..dee72c7 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body @@ -0,0 +1,2 @@ +Verdict: run releases.py periodically, and post the tarballs on the +web. diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values new file mode 100644 index 0000000..2e85e56 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values @@ -0,0 +1,8 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Fri, 20 Nov 2009 21:45:50 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body new file mode 100644 index 0000000..b36292a --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body @@ -0,0 +1,55 @@ +"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. The version number set in +that branch is the one which determines the version of Bugs Everywhere +as a whole. + +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. + +Switching between branches doesn't change the canonical version string. + +> 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. + +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. + +-- + \ “Never do anything against conscience even if the state demands | + `\ it.” —Albert Einstein | +_o__) | +Ben Finney diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values new file mode 100644 index 0000000..3a42917 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values @@ -0,0 +1,14 @@ +Alt-id: <87d481ht1s.fsf@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Thu, 16 Jul 2009 19:32:31 +1000 + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body new file mode 100644 index 0000000..30e3cbd --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body @@ -0,0 +1,44 @@ +"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 changelog. +> +> Which we don't bother keeping (also NEWS), since "bzr log" works so +> nicely. + +That's not a changelog, that's a commit log of every source-level commit +made. Far too much detail for a changelog of *user-visible* changes +associated with a release. + +> The timestamp should at least replace the patch release number, which +> you agree is-desirable-to increase motonically ;). + +I still disagree that a timestamp is the right thing to use there. 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. + +> One problem is that we don't actually have "releases". People just +> clone a branch, install, and go. + +I agree that's a problem. I think the solution is to start making +releases, with specific version strings, as source tarballs. + +James Rowe <jnrowe@gmail.com> writes: + +> Isn't there a bzr web interface that at least supports creating +> tarballs/zips? + +Even better: ‘bzr export /tmp/foo.tar.gz’ will create a source tarball +of all the files in the branch's VCS inventory. All we need to do is +start the practice of tagging a release in the VCS, and export the +tarball at that time. + +-- + \ “Pinky, are you pondering what I'm pondering?” “Well, I think | + `\ so (hiccup), but Kevin Costner with an English accent?” —_Pinky | +_o__) and The Brain_ | +Ben Finney diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values new file mode 100644 index 0000000..56bef0b --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values @@ -0,0 +1,14 @@ +Alt-id: <87k52bjoxe.fsf_-_@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Wed, 15 Jul 2009 00:54:05 +1000 + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + |