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
