diff options
Diffstat (limited to '.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body')
| -rw-r--r-- | .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body | 102 |
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 |