On Wed, Oct 30, 2002 at 02:06:39PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > No... it needs to be called 0.14.5.
> >
> > It is quite possible that people grabbed the 0.14.4 tarball. We want to
> > ensure that when problems are reported, that we know which tarball they
> > grabbed.
> >
> > And yes, this also means that some of the changes since 0.14.4 will be
> > incorporated into the new 0.14.5 (e.g. xml logging and Karl's prop work).
> >
> > Release numbers are cheap. Use them. :-)
>
> <displeasure level="very mild">
Oh. Well, let me just turn up your Cranky Meter a bit :-)
> Next time, let's please call it "0.14.4b" or "0.14.4.2" (just by
> tweaking the minor number in svn_version.h appropriately).
svn_version.h defines three *integer* values so that versioning can be
programmatically detected and managed. We don't have a system for ".4b" or
".4.2" types of numbering. Adding such a thing would certainly be possible,
but I don't see that it is needed. We have a strong definition of versioning
(based on the APR definition), and adding the extra numbers isn't going to
help.
> Release numbers are only cheap when used like rational numbers :-).
The numbers *are* cheap. The root of the issue here is the *external* uses
of those numbers. Specifically, we have:
* issue tracking
* status/release page
* human discussion/perception
If you can reduce the external dependencies, then the numbers are right
where they belong: cheap.
* issue tracking: we could start using names rather than numbers, and then
just assign a name to a particular number. Adding this level of
indirection will work for the issue tracking, but it requires that we
clearly associate a name with a release. After seeing a bunch of
childish names associated with Open Source projects (I'll avoid pointing
fingers, cuz I don't want to embarass some of the GNOME folks... oh...
oops :-), I don't really enjoy naming releases. Especially patch-level
releases. Maybe if we just stuck to simple things like "eagle" and
"sparrow" and "robin", then we'd be okay.
Without a level of indirection, the issue tracker is simply going to be
messed up. Or... we could use dates. "mid-November" or "end-November".
If we plan to stick to regular releases, then this will work fine. And
since the actual date is fuzzy, then "mid-November" seems all right. Of
course, if each release "slips" by a few days, we'll end up fixing
"mid-December" issues in January :-)
Lastly, people should always be wary of "oh, issue #XYZ will be fixed in
SVN A.B.C". Unless and until the community gets a marketing department
making commitments to customers, then those markers are advisory rather
than toe-the-ine commitments.
* status/release page: concentrate on release date first, numbering second.
If the page says "Mid-November: Subversion 0.14.6", and the issue
tracker concurs, then people will not rely on the number as much.
* human discussion/perception: is this really a problem? People are aware
that we zoomed right past .4 and that .5 is the latest release. And
awareness can be enhanced by updating the web page to say "0.14.4 was
released, but pulled due to a problem with its logic for locating
Berkeley DB". Apache has skipped quite a few numbers in its release, and
it doesn't seem to cause much problem. Of course, there is no milestone
management in its issue tracker, nor a list of future releases :-)
All of this sort of requires answering the question "why do we want the
numbers to be 'cheap'?" Simplicity. Once you start tacking on letters or
additional parts, or this or that, then the rules surrounding those numbers
become much more difficult. And the tradeoffs for dealing with "lost
versions" is much less than the long-term effects of a more complex
versioning system. (this is why I was so hinky about Brane's initial version
numbering stuff; very flexible, but the interactions between all the bits
was hard to grok)
We get long term simplicity, and hard and fast rules/doc for the use of those
three numbers. But we get some exposure to "lost versions".
>...
> bigger. Also, it's a little misleading to increment the first minor
> number for such a small change -- that is, for a tiny bugfix to an
> interim release, rather than a full interim release.
MAJOR.MINOR.PATCH. I think the change in number was quite fine for what we
did. Since we haven't hit 1.0 yet, the versioning restrictions on API
compatibility aren't really being applied, but that patch level *does* mean
"just a bug fix; zero source/binary API changes".
>...
> Version number aside, I purposely waited until after the release to
> commit that prop work. Although it's probably fine this time, in
> general, we should look at the trunk commits between the inital
> release and the bugfix release, determine whether they are really 100%
> innocuous, and not hesitate to make a temporary branch for the bugfix
> release(s).
Ben and I were chatting on AIM while we he was rolling. Looking at the log
was part of that. If there was something ugly, then 0.14.5 would have come
off a branch :-)
> "Branches and tags are cheap. Use them. :-)"
"Branches and tags are cheap. Use them if necessary. :-)"
:-)
> P.S. I've shifted the milestones and will take care of
> project_status.html later.
Cool. Like I mentioned, leaving a marker that says that 0.14.4 was pulled
would be good.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 31 22:49:23 2002