[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>

Okay. I've got Ruby compiling. I'm attempting to get everything in

17 messages 2006/01/05
[#7058] Re: More on VC++ 2005 — nobuyoshi nakada <nobuyoshi.nakada@...> 2006/01/06

Hi,

[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)

Hi,

22 messages 2006/01/10
[#7097] Re: mathn: ugly warnings — Daniel Berger <Daniel.Berger@...> 2006/01/10

Hadmut Danisch wrote:

[#7098] Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/10

Daniel Berger wrote:

[#7118] Re: Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/12

*Dean Wampler *<deanwampler gmail.com> writes:

[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>

Hello,

23 messages 2006/01/28
[#7228] Re: Question about massive API changes — Caleb Tennis <caleb@...> 2006/01/28

>

Re: Fwd: Re: Question about massive API changes

From: Jacob Fugal <lukfugl@...>
Date: 2006-01-31 04:34:47 UTC
List: ruby-core #7253
On 1/30/06, Charles Thornton <ceo@hawthorne-press.com> wrote:
> 2) Now for the "I will probably be stoned answer" -- If anybody employed
>     either full time or consultant UPGRADES Language Release without
>     being aware of any compatility issues between one version and the next
>     I'd fire his butt.
> 3) Nobody is FORCED to Upgrade and break code.  It is a CHOICE beween
>     Adjusting your code or living with your current verion (say 1.8.4).
>     Which by the way works very well.  I only languages I know of that
>     don't break something between major releases are DEAD ONES.

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.

Jacob Fugal


In This Thread