>> certainly the big fixes will be different (in that sense, 1.4.1 and
>> 1.4.2 are merely more "mature" descendants of 1.4), but the features
>> will all be the same, no?  and 1.4 won't have any features that 1.4L
>> lacks, will it?
>
>Depends on what you mean by features.  Could well be that entire
>programs are removed from the source tree between 1.4 and 1.4L...  8-)

yeah...i know.  or moved, as in the case of, for example, nfsd between
1.1 and 1.2H.  :)

>> >As a matter of policy, things must be done -- possibly differently
>> >("the right way") -- on the trunk before they are done on the branch.
>> >Which means, in some sense, in terms of bugs and features, you could
>> >claim that "1.4A" is a descendent of the "1.4".  However, if you're
>> >going to apply that metric, then similarly there is some revision x
>> >for which it can be said that 1.4x contains all of what is in 1.4.1,
>> >etc. (at worst, the value of x on the trunk when 1.4.1 is released).
>> 
>> sure.  but i'd argue that 1.4.1 and 1.4F are siblings at best, or
>> perhaps, more properly put, cousins; no direct descendant relationship
>> is attachable (is that a word?).
>
>So, pick one.
>
>If you want to use features as a metric, you have to
>call 1.4x a descendeant of 1.4.1 if you call 1.4A a descendant of 1.4.

i'm obviously doing a very bad job of convincing you that i'm not
completely confused.  perhaps what i'm searching for is that last
epsilon version of -current that was 1.3x from which 1.4A and
1.4-release sprang.  if had a better name for it, i'd use that.  but i
don't.

>If you want to use code branching as your metric, then neither are
>true.

true.  the code-branching is always more complex.  but it doesn't
always reflect what the world sees, which is generally "releases",
"patch releases" and "current".  not everyone is entirely cognizant of
the nigh-infinite number of branches from -current (like the softdep
branch or the bounce buffers stuff).

>> if i was to draw a straight line
>> that was current, like this
>> 
>>  1.0
>>   |
>>  1.1
>>   |
>>  1.2
>>   |
>>  ...
>> 
>> where these are the -current source code (and they all have letters),
>> then 1.2-release would (in my mind) branch sideways (to the right) at
>> the same point that 1.2A was "created".  1.2.1 would go sideways from
>> that (1.2-release) and 1.2B would be further down the page.
>
>uh, no.

oh.  :(

>The correct representation of the relationship can be found, for
>instance, at:
>
>	http://www.netbsd.org/Releases/release-map.html#NetBSD-release

yeah, i've seen that, and referred people to it at times.  i'm jsut
trying to simplify it a bit here.  to no avail.

>(it's worth noting that, now that you can get things via cvs, of
>course, you can get to the trunk even as a release branch is being
>stablilized for actual final release.)

yep.  that part i knew.

>Here's a riddle for you:
>
>if 1.4A is to be considered a descendant of 1.4, how is it that
>the revision 1.4A can appear to developers and even the public (e.g. in binary
>snapshots) before 1.4 is finalized?  we even got to 1.4B before 1.4
>was final, this last time aroudn...
>
>You can't really be a descendant of somebody who came after you.  8-)

1.4-release was still "being born" at the time that 1.4A came "out".
it was a long, arduous labor and then it spent six weeks in the nicu.
1.4-release is less featureful than 1.4A, but they are definitely
related.

>> >It is obviously wrong to claim that there's some revision 1.4x which
>> >is a descendant (by any metric which actually involves source code
>> >origin) of 1.4.1.  The relationship between 1.4 and 1.4A isn't quite
>> >as obvious, but, in the same way, it is untrue to say that 1.4A is a
>> >descendant of 1.4.
>> 
>> that's true.  i wasn't trying to claim that at all.  merely that 1.4K
>> and 1.4.1 have some common ancestor.  they are both, after all,
>> descended from, say, 1.3M, no?  even if the features that 1.3M has
>> aren't *all* represented in 1.4-release.
>
>And, similarly, 1.4 and 1.4A have a common ancestor (1.3M, if that's
>the right letter, but more properly called netbsd-1-4-base).

yeah!

>1.4A is netbsd-1-4-base + some set "X" of changes.
>1.4B is netbsd-1-4-base + some set "Y" of changes.
>1.4 is netbsd-1-4-base + some set "Z" of changes.

okay.  then netbsd-1-4-base is the name i'm looking for, but never
actually used, since it's a cvs tag, and not a version tag (like 1.4,
1.4.1, and 1.4G are).

>X is a proper subset of Y.
>
>That is the only relationship between those sets of changes.

and Z?  Z is a set of some members of X and some members of Y (albeit
retrofitted), and some other fixes.  no?

>If you want to look at it from the "sets of changes to features/bugs"
>standpoint, then maybe you can make a stronger claim, but you've
>already discounted that in the 1.4.1 vs. current case.

i didn't mean to...really.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."