On Wed, Jan 31, 2001 at 04:57:39PM -0500, Braden McDaniel wrote:
>
> Funny you mention GL. I clearly remember Stephen Baker railing against the
> situation of having multiple GL libraries installed on the system.
> Apparently this has been a major headache for GL developers and
> especially end users. I wish I could find the message, but I think it was
> on the old Mesa list (before they moved the list to SourceForge) and I
> can't find an archive. Of course, the *theory* of what you describe is
> sound, just as the theory of COM's versioning is sound. It's in actual
> implementation that things run afoul. Too often, the contract *isn't*
> obeyed. Sound familiar?
I've had good luck with multiple GL installations. It takes some human
mucking to move files around appropriately depending what you want to do.
But I've kept both a hardware driver and a Mesa software driver, for
example, ready for use depending what I needed. I agree, it breaks as often
as it works.
>
> Any versioning system involves some rigorous attention to detail whenever
> release time comes around. That is unavoidable. Developers must be
> familiarized with where that attention is needed, and proper protocol
> must be observed. This is important enough that it needs to be checked
> and double-checked.
And the packaging/installation story needs to be well in place. Mozilla is
actually in fantastic shape as far as that goes -- it depends only on very
standard stuff, and keeps all its own stuff nice and out of the way (and
harm's way).
>
> Brendan says that Mozilla is "limping along" on COM's versioning system.
> But from what I can see, Mozilla is barely using COM's versioning system.
> As with the GL library problem (which is subsiding on Linux at least, now
> that Mesa is bundled with XFree86), I think this is more a problem with
> the implementation of the theory rather than any fundamental flaw in the
> theory itself.
Again, I don't see the evolutionary-interfaces theory of the COM gurus being
used successfully *anywhere*.
I think the interfaces change too often and too subtely to make "new
functionality requires a new version of the interface, which supports the
old version" a reality for the internal version story (i.e. what happens
between mozilla developers as mozilla advances from one release to another).
Supporting old interfaces while creating a new interface *every* time you
change something is just *way* too much of a burden on developers.
Clearly developers need to be free to have stuff swim around loosely between
releases, and only lock things down when say minor releases come out (i.e.
1.0, 1.1, 1.2). That's quite reasonable -- anyone crazy enough to develop
against nightly CVS has got to be ... pretty crazy :)
But then the question arises: why bother supporting all the old interfaces
along with the new ones? Since *every* damn object in there is slowly being
phased out with respect to its newer implementations, you have a continual
flux, and you never know when you can finally kill an old interface that's
hanging around. Maintaining all that old stuff remains too much of a
headache. MS runs into this with the "we still love IOldFoo, it's great, but
please, buy INewFoo!".
So what's the traditional answer?
a) Move all the versions at the same time, i.e. at minor version changes
b) support multiple installations (mozilla does this fine already).
now you can kill old interfaces without worrying -- anyone who needs
backwards compatibility can just install an old version. the caveat is that
you have to support the old version as far as critical bugfixes/security
updates goes. so you have to fork the CVS tree.
But why is that unreasonable? every other major project (the kernel, GNOME,
KDE, gimp, you name it) has both a stable tree and an unstable tree.
but now that you've got a consistent version number story for doing API
changes (i.e. the API will remain constant across revisions of a minor
version, and will change between minor versions), you can just change the
interfaces without supporting old ones or renaming them :) and now we're
*exactly* where the rest of the (sane) world is.
What did the COM gurus think they were fixing, exactly?
...
Moral of the story: we've come to clear agreement here. Theories are all
well and good, but *implementations* count most :)
as long as we've got bugzilla screaming at us if something goes majorly
wrong, i think we'll be in moderately good shape.
ari
