On Sat, Oct 20, 2001 at 04:34:03PM -0400, Greg A. Woods wrote:

 > I did.  Kre did.  I think greywold and mcr did too.  I've _ONLY_ been
 > talking about releases.  In fact I've only been talking about __MAJOR__
 > releases.  What the heck did you think I was talking about!?!?!?  "make
 > build"!?!?!?!?!?!?
 > 
 > I've only used the pharase "major release" about a zillion times in this thread!

Yes, we know what you're talking about.  You've mangaed to repeat yourself
about a dozen times on this thread.  I suppose you think that if you say
it enough times, people will start to agree with you.  All that extra
punctuation isn't going to pursuade me, either.

In any case, there is no real harm in continuing to do things the way
we (that is, the people who act as system architects for the NetBSD
Project) are currently dealing with the ABI versioning issue.

And, if we were to select your way, there could be significant, annoying
pitfalls at "major release" time (nevermind that just defining what exactly
constitutes a "major enough" release is an issue that we haven't even touched
on yet), for what amounts to zero tangible gain.

So, let's review:

	"Our way"	No significant overhead, maintains full ABI
			compatibility with all previous NetBSD releases.

	"Your way"	Chance of screwing over users[*] at upgrade time
			for basically no gain.

The choice is pretty obvious to me.

[*] We haven't even touched on the "no way to rebuild old app because
vendor either doesn't exist any more, or source code for mission-critical
app simply no longer exists".  I know of at least one NetBSD developer
who was paid a good chunk of change to ensure this type of application could
continue to run on an updated NetBSD system.

Anyway, I think it's safe to say that the current practice of doing
symbol renaming for ABI versioning is not going to change, unless some
better way of maintaining full ABI compatibility comes along.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>