[Pkg-parrot-devel] Parrot 4.0.0

[Patrick R. Michaud]

On Sat, Apr 07, 2012 at 09:46:21AM -0700, Allison Randal wrote:
> On 04/07/2012 09:15 AM, Alessandro Ghedini wrote:
> > 
> > Actually, I have uploaded it just now (I was kind of waiting for 
> > your response, though I've not been explicit). I agree with you 
> > anyway, but I think (and hope) that the rakudo (and nqp) release 
> > and development process will change as soon as a "1.0" release 
> > will come near.
> 
> That could be years in the future. [...]

...or years in the past.  

FWIW, within the Rakudo development team we don't think of ourselves 
as building up to an eventual "1.0 release" -- we think of our 
"1.0 release" as having occurred sometime in the past (e.g., in summer 
2010).  As far as we're concerned, we're already in something
of a "post-1.0" environment.

Many people can justifiably argue that Rakudo isn't stable or 
complete enough to be called "1.0" yet, and I can completely
understand that perspective.  But when we try to pin folks down
on what they would expect from "1.0" that Rakudo doesn't have now, 
we find that either (1) we've already achieved it,  (2) they're looking
for features that we expect to be evolving in the context of
a user community (e.g., an equivalent to CPAN, which I posit
is generally a post-1.0 development for *any* language), or 
(3) they expect things that are relatively unbounded, only
vaguely described, and/or not really compatible with ongoing 
Perl 6 evolutionary constraints.

Thus we largely conceive that Rakudo has already entered a phase 
of its lifetime where improved stability, completeness, and 
usability will come about through continued incremental evolution 
and increased adoption over time.  To me, that's a "post-1.0" state
of affairs for a programming language.

So to return to the original thread: we don't have a "1.0"
target in our future that might spur development in a particular
area such as release process.  Instead, like any product we tend 
to respond to the needs articulated by our client base.  This
client base definitely includes packagers.

If Rakudo's release and development process aren't supporting 
packagers well, we're very eager to making improvements quickly.  
Just keep in mind that nearly all of the release/development process 
we have in place today for Rakudo exists because of the current and
ongoing realities of developing for Parrot, and not because
we're lazy or uncaring about the packaging process. 

Pm