Re: Ruby 1.8.7-preview1 has been released

Hi,

At Thu, 17 Apr 2008 00:09:58 +0900,
Florian Gilcher wrote:
> I'm citing a message from talk, but I think it better fits into core:
>
> On Apr 16, 2008, at 4:40 AM, Pena, Botp wrote:
> > chuck-full, this looks like ruby1.9 without the vm :)

I may digress, but Ruby 1.9 is far more than just VM.  There are so
many fancy things we regret being unable to backport.

> Thats pretty much why i'm not looking forward to the 1.8.7 release.
>
> Ruby 1.8 is the major ruby version that is marked production-ready.
> While there are cases where changes are necessary, this should mean
> that the API is stable - at least when it comes to core classes, but
> to some extend, this should also be true for the standard library. The
> core should be frozen.

It all depends on your standpoint, really.

If you are a mission critical production application developer, you
would just want bug fixes and nothing else.

If you are an average production application developer, performance
improvement would also be welcome.

If you are a library developer, the bigger the difference between 1.8
and 1.9 the more difficult it is to develop and maintain your library.
If you drop support for 1.8, you are leaving average users behind.  If
you stick with 1.8 and hesitate to support 1.9 until it is production
ready, you are left behind when 1.9 is ready.  So changes that makes
1.8 closer to 1.9 may help you.

If you are a bleeding edge developer, you couldn't care less about 1.8
as you say.

But after all above, if you are a Ruby developer like me, you must
care about all kinds of people using Ruby in various ways.

I'll tell my thoughts in detail below.

> Those changes are not minor. While they are backwards-compatible, they
> severely break forward-compatibility between 1.8.6 and 1.8.7. While
> those changes are nice, it gets increasingly hard to track what
> features a specific minor(!) core(!!) version of Ruby  actually
> supports. As there are still many interpreter installations out there
> that are not even  on 1.8.6-level those features are essentially
> useless. For example, some Linux packaging tools do not even install
> 1.8.6 (apt for example). If you target your code towards a minor
> version, you will  be in a world of pain. As developers often use the
> most recent version for development, chances are there that you run
> into that trap. You can multitest, but it artificially increases
> testing complexity. This is beginning to get a real problem when it
> comes to configuration management.
> Also, as we do have multiple interpreters for the standard-1.8.6-
> distribution, it breaks compatibility for those.

You could think about forward compatibility between 1.8 and 1.9 as
well.

To encourage users to stop using a feature in 1.8 that are deprecated
in 1.9, it is sometimes an optimal solution to backport the new method
to 1.8.

Generally the newer version is (re)designed based on better methods,
styles and techniques, so it is often a good idea to make people get
used to them through backports, rather than asking them to make big
changes after a long time has passed.

> There are cases where backporting would make sense (in edge cases
> where there is really only a brutal hack in use [e.g. #instance_exec,
> which does not seem to be backported]).  But in case of all those
> Enumerators:  If I use them, my code breaks on all older versions. So,
> any sane person keeps his hands off them. Where is the point in
> supporting them?

It doesn't make much sense to me.  Why would users who stick to older
releases of Ruby suddenly decide to introduce a new library, or use
new features when writing one?

You probably know but there are the Ruby 1.8.X-pX series for the last
two releases for those who don't want changes but just bug fixes.
Considering 1.8.5 was a bug fix release of 1.8.4, it has been
maintained for more than 2 years.  Even if the 1.8.5 maintenance were
to be dropped, you could then move to a newer release without much
difficulty, because backward compatibility is kept pretty well and a
few exceptions are documented.

> I also believe that the invested time in backporting is better
> invested to improve ruby1.9.

Backporting a radical development branch to a stable branch is like
making steps for gradual migration instead of giant leap migration,
which often demands you a complete rewrite of a big part of your code.

If you froze a branch soon after the first or maybe second release
from the branch, what would happen?

As the difference between ruby branches gets bigger and bigger, every
library author would:

a) Have to maintain one branch for each ruby branch,

b) Write and maintain bridge code on his/her own,

Or:

c) Feel conservative about using new features aggressively, and the
   new features would not get used as hard as they deserve.

What we have been doing in the 1.8 development is eliminating each
developer's duplicated effort of a) and b) to avoid the worst case,
c).

If people did not use or even know about new features for a long time,
the development branch would eventually be full of experimental,
untested features.  Decent tests would not be performed widely until
after several years of aggressive development, while the stable series
solely enjoys its heyday without any changes.  Then one day, when the
first release from the development branch is about to release, you
will be told: "OK, the new version of ruby is getting ready.  Before
we release it, we would like you folks to test these 1000 new features
with your applications and libraries.  Beware, you'll have to fix your
code around before running it with the new version if you are using
any of those 100 features that have incompatibilities with the
previous series".

It is not my imagination.  Similar things actually happened a few
times before, albeit the figures above are a bit exaggerated.  Every
time that happened the average user got confused by and complained
about the incompatibilities and unknown new features suddenly
introduced when a new major version was released.  That caused the new
version to take much longer time than expected to become stable and
get widely used.  We used to lose users because of all that.

> I support and like Rubys bazaar-style development, but a bazaar begins
> to fall apart when huts change their position every other day.

As I said above, we have been improving the development scheme to
offer reasonable options for various kinds of users and scenes.  I can
say we have been and will always be consistent with that.

> There are multiple solutions to this problem:
> * freeze the core-api for major versions upon release candidates.
> * freeze the core-api before developing a new release (python style).
> This might not fit the usual ruby development style but would make it
> easier for non-mri interpreter teams to develop some kind of standards
> ahead of an MRI release.
> * provide a backport-library (or gem) that implements those features
> for all older  versions of a series (can be hard in some cases) that
> all developers of "edge"- libraries can depend on.
> *  be sane about adding features inside a series. Ruby is rich on
> sugar, but you should not add sugar to a cake that is already
> finished. "Sane" is intentional: make a lax statement on what should
> and what should not be added in a minor version, without specifying
> hard rules. This means that a discussion is needed on whether those
> changes were "sane" or "not sane".
>
> Also, this kind of release policy is known in the administrator world
> and it gets increasingly hard for me to get people to even consider
> ruby because of it's erratic nature when comes to the core.

I agree.  Sooner or later we will have to make a switch, but I don't
think we are ready to go for that.  For 1.8 and 1.9, it's so late it
doesn't pay.  Maybe from 2.0?  It's matz's call though.

--
Akinori MUSHA / http://akinori.org/