On Wed, 21 Feb 2001, Conrad Schneiker wrote:

> James T. Vradelis wrote:
> # then I'd volunteer to fix whatever that breaks.
> 
> Fixing libraries is the easy part--that is just the lookout tower on the
> mountain of Ruby code in the world. And most of the rest of that code
> people don't want to hand over to strangers to fix. 

Good point.

> Indeed, they don't want it broken in the first place. And they don't
> want the door opened to repeated breaks for other good ideas. This
> is an unfortunate fact of life that must be a high priority decision
> criteria if Ruby is to become widely regarded as a serious
> development programming language.

I think things are regular enough, if we just keep them that way in
the future too. The usual story is

  major version update probably breaks some code
  minor version update shouldn't

Then it's about keeping things this way. Could be hard, or might not
be. (BTW. note minor version didn't say "will not ever break".)

If you have production system which runs fine, you _dont_ want to
upgrade to a newer version. Because if you do, and it happens to be a
major revision then you have to accept the fact life you might have to
update your source code too. You have to accept the fact of life you
might have to update your source code even when doing minor upgrades.

No gains without potential pains.

I agree we should minimize even major release griefs, but I think it's
completely understandable to have them. No one forces anyone to take
updates.

OTOH, if upgrading to a newer version proves to be too difficult but
still wants the candies there's a way. This is open source after
all. Just wrap up your own 1.6.2_with_1.7_gc version by backlogging
1.7 enhancements into earlier part of source tree. If it's useful
enough you'll get many fans by giving out it to other people having
same problems.

    - Aleksi