Merged Trevor's tree

1 files changed, 0 insertions, 102 deletions

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