I see little point in versioning or emulation until we have spec
versions and complete test suite versions that can validate them.
And I see no need to "practice" versioning before that happens; it
will just slow down the drive to complete 6.0.0, and there will
(I hope) be time to consider the fine
Em Sáb, 2010-03-20 às 22:23 +0300, Richard Hainsworth escreveu:
> Here it is the very language that is changing.
> For instance, =$fh was used to generate input from a file. Now it is
> $fh.lines
Note that I did mention versioned dependencies for grammar, CORE and
setting. So yes, considering the
On Saturday 20 March 2010 at 12:23, Richard Hainsworth wrote:
> In other words, I am suggesting a sort of mapping of the syntax of perl6
> so that stable areas can us be used, perhaps avoiding instruments that
> are not yet explicitly stable.
That assumes it's possible to know with sufficient c
Not really a versioned dependencies.
When a working module is updated to have new functionality, the old
version continues to work.
Here it is the very language that is changing.
For instance, =$fh was used to generate input from a file. Now it is
$fh.lines
Old examples that I wrote using
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,
backwar
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 compatibili
