Daniel Ruoso wrote:
Em Sáb, 2010-03-20 às 12:16 +0300, Richard Hainsworth escreveu:
Suppose we define a domain of stability as syntax/functionality/features that will not be changed until a milestone is reached, with the guarantee that if the language specification changes before then, backwards compatibility will be retained so that the syntax/feature/functionality will continue to function without a need to change it or the surrounding code.

I think this is more a case for versioned dependencies.
I'm not sure this is written down anywhere in the spec, but I guess
there should be a way to tell "this code was written targetting version
$x of the implementation $y" - if the code is compiled to bytecode that
is really easy.

Then the implementation might have a way to adapt itself to provide the
intended semantics.

Of course this requires an entire different set of maintainance
challenges, including a very precise delta documentation and probably a
lot of coercion functions, i.e: coerce from Int version 0.003 to Int
0.004 back and forth.

That way we have both the grammar, the CORE and the setting being
versioned, and it will be easier to adapt for the future...

Declaring the semantics you require by version is good.

However, especially in these earlier days when lots of things are still changing, I think it would be onerous for Rakudo to actually support coersion for old semantics in general.

So in the short term I see it reasonable for Rakudo to just support its current version, and when it encounters code expecting an older version of semantics, to just throw up an error message saying it can't run this and please use X version of Rakudo to run it. Or as a midway, Rakudo could support specific older versions on a case by case basis.

I see 2 most-reasonable options in the short term:

1. People writing applications now could just tell their users, this requires version X of Rakudo, so make sure to install that version rather than the latest. This should be reasonable short-term, but said users should expect that they can get an updated version that works with the then-newest Rakudo say every year or 6 months or whatever.

2. Rakudo could follow Parrot's example of having more end-user focused releases every 3 months (2.0, 2.3, 2.6, etc) and just support emulation of semantics for the versions of Rakudo that correspond to those more stable Parrot releases, essentially treating them like more-stable Rakudo releases. Then, as long as the program specifies one of those every-third Rakudo versions, it will run with the latest Rakudo, for at least a year's worth of Rakudo releases since the version they require comes out.

That's what I suggest for calendar 2010, starting with Rakudo * which as it happens would correspond to Parrot 2.3 if released in April; make that the oldest emulatable version, if you want to do that. And then re-evaluate or change the support strategy a year later.

-- Darren Duncan

Reply via email to