From: Aredridel Date: 2004-11-18T07:43:38+09:00 Subject: Re: [ANN] rpa-base 0.2.3 > > 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