Greg Stein <gstein@lyra.org> writes:
> If you can reduce the external dependencies, then the numbers are right
> where they belong: cheap.
Understood -- I love cheap numbers too. But...
> * 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 :-)
Named levels of indirection *always* end up being confusing. People
can't remember what name goes with what release; outsiders coming in
for the first time are lost in a swirl of arbitrary names and no idea
how they're ordered. Does "Woody" come before "Anaerobic Brachiator"?
Does "Spotted Ungulate" come before "Dancing Arthropod", or is it the
other way around? Who can say? I hate that whole system so much;
let's please not go there. Everybody loses.
Dates are ordered, but the trouble is, they're dates :-). They can't
be moved, they can only be overshot.
> 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".
Good point. Hmmm...
You know, I think I missed the obvious answer here: rather than add a
fourth number, why don't we start using the *third* number the way we
always said we would?
In other words, instead of insisting that Beta is 0.15, let's just not
specify what Beta is, and start number our next interim releases like
this:
0.15.0 (and bugfix releases would be 0.15.1, 0.15.2, etc...)
0.16.0 (and bugfix releases would be 0.16.1, 0.16.2, etc...)
I think that solves all of our problems.
What d'y'all say? I'll wait for responses before updating the status
page & issue tracker appropriately.
> Cool. Like I mentioned, leaving a marker that says that 0.14.4 was pulled
> would be good.
Check, thanks.
> 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.
Sure, they're advisory, but they're not meaningless. Associating
issues with ordered milestones is less important for mature projects
like Apache, which are already in production use at many sites.
Subversion has an urgent need to prioritize, and tracking issues this
way has been a lifesaver, for all the extra burden it imposes. (But
+1 on reducing that burden if we can!)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 31 23:42:58 2002