diff options
| author | W. Trevor King <wking@drexel.edu> | 2009-12-13 06:19:23 -0500 |
|---|---|---|
| committer | W. Trevor King <wking@drexel.edu> | 2009-12-13 06:19:23 -0500 |
| commit | 4d057dab603f42ec40b911dbee6792dcf107bd14 (patch) | |
| tree | 9a73459aa160e3c96f4893b132543f412ca6e97f /.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments | |
| parent | dff6bd9bf89ca80e2265696a478e540476718c9c (diff) | |
| download | bugseverywhere-4d057dab603f42ec40b911dbee6792dcf107bd14.tar.gz | |
Converted libbe.storage.vcs.base to new Storage format.
Diffstat (limited to '.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments')
48 files changed, 0 insertions, 1553 deletions
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body deleted file mode 100644 index fa9e963..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body +++ /dev/null @@ -1,36 +0,0 @@ -* 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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values deleted file mode 100644 index e7077e7..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body deleted file mode 100644 index 8c890f3..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body +++ /dev/null @@ -1,27 +0,0 @@ -"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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values deleted file mode 100644 index 3b45fbf..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values +++ /dev/null @@ -1,11 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body deleted file mode 100644 index 7e1434b..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body +++ /dev/null @@ -1,115 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values deleted file mode 100644 index 9e84a24..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body deleted file mode 100644 index a0b6a14..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body +++ /dev/null @@ -1,58 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values deleted file mode 100644 index 320c484..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body deleted file mode 100644 index 5f478b5..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body +++ /dev/null @@ -1,96 +0,0 @@ ------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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values deleted file mode 100644 index 8cfe1b0..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body deleted file mode 100644 index b34e037..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body +++ /dev/null @@ -1,52 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values deleted file mode 100644 index e0c0955..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body deleted file mode 100644 index 4ebb4f2..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body +++ /dev/null @@ -1,51 +0,0 @@ -"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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values deleted file mode 100644 index b45a747..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body deleted file mode 100644 index 7ffe231..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body +++ /dev/null @@ -1,38 +0,0 @@ -[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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values deleted file mode 100644 index 4f1d60d..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body deleted file mode 100644 index d00eb64..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body +++ /dev/null @@ -1,22 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values deleted file mode 100644 index 4fb068d..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body deleted file mode 100644 index 24ff7b0..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body +++ /dev/null @@ -1,58 +0,0 @@ -"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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values deleted file mode 100644 index c5d9cbb..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body deleted file mode 100644 index a3fc57f..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body +++ /dev/null @@ -1,36 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values deleted file mode 100644 index b6d25cb..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body deleted file mode 100644 index 5d29f85..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body +++ /dev/null @@ -1,102 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values deleted file mode 100644 index 7f205d6..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body deleted file mode 100644 index 8b32751..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values deleted file mode 100644 index 239feb5..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body deleted file mode 100644 index 33a8d66..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body +++ /dev/null @@ -1,51 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values deleted file mode 100644 index b757933..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body deleted file mode 100644 index 063afcb..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body +++ /dev/null @@ -1,30 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values deleted file mode 100644 index 466be33..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body deleted file mode 100644 index 1e2a870..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body +++ /dev/null @@ -1,37 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values deleted file mode 100644 index b5c41c9..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body deleted file mode 100644 index e02bd38..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body +++ /dev/null @@ -1,25 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values deleted file mode 100644 index 57b408f..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body deleted file mode 100644 index d8014d2..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body +++ /dev/null @@ -1,102 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values deleted file mode 100644 index c7c0273..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body deleted file mode 100644 index 4e8445a..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body +++ /dev/null @@ -1,18 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values deleted file mode 100644 index 00309a2..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values +++ /dev/null @@ -1,11 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body deleted file mode 100644 index fce4941..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body +++ /dev/null @@ -1,72 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values deleted file mode 100644 index a3f74c4..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 5eeb353..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body +++ /dev/null @@ -1,88 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values deleted file mode 100644 index 63a2cae..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body deleted file mode 100644 index dee72c7..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body +++ /dev/null @@ -1,2 +0,0 @@ -Verdict: run releases.py periodically, and post the tarballs on the -web. diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values deleted file mode 100644 index 2e85e56..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values +++ /dev/null @@ -1,8 +0,0 @@ -Author: W. Trevor King <wking@drexel.edu> - - -Content-type: text/plain - - -Date: Fri, 20 Nov 2009 21:45:50 +0000 - diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body deleted file mode 100644 index b36292a..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body +++ /dev/null @@ -1,55 +0,0 @@ -"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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values deleted file mode 100644 index 3a42917..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body deleted file mode 100644 index 30e3cbd..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body +++ /dev/null @@ -1,44 +0,0 @@ -"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/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values deleted file mode 100644 index 56bef0b..0000000 --- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values +++ /dev/null @@ -1,14 +0,0 @@ -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 - |