Aredridel
11/17/2004 10:44:00 PM
> > Since the new RubyMail will have a completely incompatible API, it is
> > de facto another library -- and no longer the original "RubyMail",
> > hence
> > the possible need for another name. RubyMail2 shows its heritage.
>
> I disagree completely. Every time I extend a class or change the
> semantics of a method I'm making an "incompatible API". That is just
> part of writing code. I'm not going to change the package name every
> time I make an incompatible release. I'd be up to ZenWeb211 and
> RubyInline39 by now. Despite all those incompatible releases, I haven't
> gotten any complaints about my package names being misleading.
You're in a relatively unique situation among framework authors:
things that depend on your framework are really rare. Frameworks like
ZenWeb lie halfway between applications, with nothing that depend on
them, and things like RubyMail or TMail, where many, many things
depend on their APIs being stable.
Do be careful when releasing incompatible APIs -- if someone depends
on the old semantics, they'll be bitten, of course, when it changes.
For some things, a little thrash is okay, but in a relatively mature
library, the thrash can set off a whole chain reaction of everyone
having to add some hack to make their library work with multiple
versions of yours, or detecting when which version is loaded, and
adjusting accordingly. Then packagers who tighten up dependencies and
make sure things all work together have to go debug that code and make
sure it doesn't get in the way.
> Further, I put VERSION in all of my main modules / classes in order to
> allow testing against to determine levels of compatibility.
Good! That helps keep the effects from rippling out so far.
> The only reason I see really needing to change the package name is if
> you wanted to have multiple versions installed at the same time and
> usable potentially by the same morass of dependencies. Having 3
> separate versions of libtool, 2 of autoconf, and 2 of automake on my
> freebsd boxen is more than frustrating. I'd rather not have that spread
> into ruby.
If libtool, autoconf and automake put version numbers in, so that
autoconf 1 was autoconf-1, autconf 2.13 was autoconf-2 and autoconf
2.57 was autoconf-3, it wouldn't be much of a problem. One would grump
about "that's silly, a number in the name, oh well". And it would
never break. As it is, dealing with multiples of those three packages
drives me nuts when working on PLD.
Spreading it unneccesarily is really bad. There's times, though, when
it's time to say "enough with this cruft, time for an incompatible
rewrite". That's when you bump the version -- or, if you're the zany,
_why-like type, you change the name from StarMonkey to CunningFox.
Either way works, though the full name change is a bit harder to
follow unless you mention "CunningFox, the successor to StarMonkey"
everywhere (not that that's bad).
There's a point in every library's life, I think, where people start
looking on it as stable; at that point, it's really nice to appease
those who aren't among the early adopters, so that one can say "X api
won't change in this branch". That's when the soname-style versioning
is really nice. It doesn't happen to every library.
soname-style versioning is appropriate for libraries like TMail,
RMail, racc, and for anything in the standard library. Any
incompatible change in these, especially if at all large, is going to
break a lot of things that depend on it. DBI's another in this
category.
ZenWeb isn't there yet. It's still used by the early-adopter sorts,
who'd spend an hour or two porting scripts to a new version, where
it's not going to break something in heavy production, or if it would,
there's a staff there to manage the update.
Then there's things like syck, where an API change would break a ton,
but there's no real reason to break the API. It's a perfect candidate
for the Raymond Chen approach: don't change it if it'll break
anything. Additions to the API only.
Ari