> > I think that would be even worse than the most dastardly of Andrew's
> > plans. The whole issue here is how to maintain maximum compatibility, not
> > how to splinter the kernel into more incompatible pieces.
>
> The point of splitting is not to splinter, but to allow those who don't
> wish to upgrade immediately a chance to think about it for a year or so.
>
> The 2.2 in this case would be a dead end. Mods to 2.2 probably would
> still be applicable to 3.0, as the only thing to be changed is the
> resource management interface (though any changes involving that layer
> are going to be a bit of a pain). In fact, 3.0 could be virtually
> identical to 2.2 but for the interface (using macros in 2.2 for old
> calls). The point is that the old interface stops at release 2.2.
So my question is why don't we just make 2.0 the last one to support that
API and have the switchover during 2.1? They'll have a year or so to
think about switching over before 2.2 is ready. That way we don't have to
split any more than we already are.
Greg Alexander
http://www.cia-g.com/~sietch/