From 4d057dab603f42ec40b911dbee6792dcf107bd14 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Sun, 13 Dec 2009 06:19:23 -0500 Subject: Converted libbe.storage.vcs.base to new Storage format. --- .../ea01c122-e629-4d5c-afa7-b180f4a8748b/body | 72 ++++++++++++++++++++++ .../ea01c122-e629-4d5c-afa7-b180f4a8748b/values | 14 +++++ 2 files changed, 86 insertions(+) create mode 100644 .be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body create mode 100644 .be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values (limited to '.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b') 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" 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 + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 09:37:32 -0400 + + +In-reply-to: 744435b7-1521-4059-a55d-f0c403d7b4d8 + -- cgit