The 'real' relationship is

		1.3A -> 1.3B -> 1.3C ... -> 1.4 -> 1.4.1 -> 1.4.2

		1.4A -> 1.4B -> 1.4C ... -> 1.5 -> 1.5.1 ...

	Each of these is an independent stream, and the orderings
	are guaranteed.

	It might make more sense to have the current number based on
	the expected next release number (it can always skip if we decide
	to do 2.0 rather than 1.5), so:

		1.5A_CURRENT -> 1.5B_CURRENT -> 1.5C_CURRENT ... -> 1.5 ->

	(substitute 'DEV' for 'CURRENT' if you want to avoid nomenclature
	clash with the existing use of current :)

		David/absolute

On 15 Feb 2000, Chris G. Demetriou wrote:

> Andrew Brown <atatat@atatdot.net> writes:
> > 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-)
> 
> 
> > >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.
> 
> If you want to use code branching as your metric, then neither are
> true.
> 
> 
> > 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.
> 
> The correct representation of the relationship can be found, for
> instance, at:
> 
> 	http://www.netbsd.org/Releases/release-map.html#NetBSD-release
> 
> (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.)
> 
> 
> 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-)
> 
> 	
> 
> > >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).
> 
> 
> 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.
> 
> X is a proper subset of Y.
> 
> That is the only relationship between those sets of changes.
> 
> 
> 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.
> 
> 
> 
> cgd
> -- 
> Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
> Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
>