Karl Fogel wrote:
>Justin Erenkrantz <email@example.com> writes:
>> Hmm. Boy, that distinction is awfully weird. How about we document
>> this in svn_version.h? I'm not aware of any other projects that have
>> x.y.z-dev being newer than x.y.z.
>Or, we should just bump to the next number immediately after a release
>(i.e., go to 0.16.2 now).
>Oh, but wait: we want to be able to insert a new minor release, but
>not be *required* to do so. For example, 0.17 is the next scheduled
>release, but we'd release a 0.16.2 if something special came up.
>So what should we bump the version number to after 0.16.1 is released?
Isn't the issue what the label should be for an interim version? That is, it's
not an official release at all; but it still has a label associated with it.
You don't want to call it 0.16.1, because it's after that. You don't want to
call it 0.16.2 or 0.17 because it's before either of those. And this label will
persist for every revision between 0.16.1 and whichever official release comes
next -- it doesn't identify one particular repository version the way an
official release label does.
So what should this label be? As Justin points out, 0.16.1-dev is misleading
because it sounds like a description of something leading up to 0.16.1, rather
than something that follows it. Here's a couple of suggestions: "0.16.1+";
>> The problem is if you don't know what your next version number will
>> be. httpd sort of gets around this by having stable/unstable version
>> numbers. (APR sort of has this same problem - there isn't an ability
>> to release unstable releases in its versioning scheme.) -- justin
Subversion effectively has two different version numbers: the label and the
repository revision number. The label is more human readable; the revision
number is more precise. You just need to come up with a label that is imprecise
for all the revisions between releases.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jan 10 21:26:58 2003