On 1/30/06, Jacob Fugal <lukfugl / gmail.com> wrote:
> Amen. It's already been determined that 2.0 will be a non-compatible
> release. Anyone that upgrades from 1.8.x to 2.0 will have to fix
> *something*, and this can be one of those somethings. If you document
> the breakage in BIG RED LETTERS, I don't see any problem with
> including the optimized version alone in 2.0 (and by extension in 1.9,
> which is the development branch for 2.0).
>
> As far as making it available for 1.8.x, just create a shim-patch in
> the form of a gem or whatever other form of package you want. Early
> adopters who can't run 1.9 for some other reason can apply the patch
> and be ahead of the game for the ->2.0 upgrade where they'll only need
> to remove the require line for the patch.

Sean-

As somebody who has made frequent use of REXML, I'd have to agree with
Jacob here. I think REXML is fantastic and the idea of having a more
memory efficient version of it sounds like a great idea. That being
said I don't see why you need to concern yourself with trying to make
it compatible when it's going into Ruby 2.0 and as everybody already
knows, so much is going to change in that release of Ruby that's going
to break older programs... people are just going to have to deal with
it. Last I heard block semantics were totally getting twiddled with...
which would mean that everything I have that uses REXML will probably
need to get changed right away, as I find myself frequently using the
REXML::XPath.each calls. Break away, but maybe release the new version
early so those of us that are aware can try to fix ASAP.

And to totally go out of thread order here, I believe what mathew was
suggesting with an API fascade was to create a wrapping layer around
the new APIs that behaved like the old APIs. Depending on how sweeping
your API changes are, it might not be too difficult to do that using
unit tests that have already been developed. Just a thought...

Cheers,

Ben