Rakudo Perl 6 development release #17

brian_d_foy on 2009-05-28T23:12:00

On behalf of the Rakudo development team, I'm pleased to announce the May 2009 development release of Rakudo Perl #17 "Stockholm". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the May 2009 release is available from http://github.com/rakudo/rakudo/downloads .

Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo .

Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. This release is named "Stockholm"; Stockholm Perl Mongers will be holding a Perl 6 hackathon on May 29 [3]. Perl 6 developer Carl Mäsak is a member of Stockholm Perl Mongers and a main author of November [4], Druid [5], proto [6], and other Perl 6-based packages. Carl also contributes patches to Rakudo, and has been stress-testing Rakudo over the past year, submitting nearly 400 bug reports.

In this release of Rakudo Perl, we've made the following major changes and improvements:

  • Rakudo is now passing 11,342 spectests, an increase of 875 passing tests since the April 2009 release. With this release Rakudo is now passing 68% of the available spectest suite.
  • We now have an updated docs/ROADMAP .
  • Errors and stack traces now report the file name and line number in the original source code.
  • Some custom operators can be defined, and it's possible to refer to operators using &infix:<op> syntax.
  • We can start to load libraries written in other Parrot languages.
  • Regexes now produce a Regex sub.
  • More builtin functions and methods have been rewritten in Perl 6 and placed as part of the setting.
  • There are many additional improvements and features in this release, see docs/ChangeLog for a more complete list.

The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compiler@perl.org mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#18) is scheduled for June 18, 2009. A list of the other planned release dates and codenames for 2009 is available in the "docs/release_guide.pod" file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month.

Have fun!

References:
[1] Parrot, http://parrot.org/
[2] Stockholm.pm, http://sthlm.pm.org/
[3] Stockholm Perl 6 hackathon, http://vic20.blipp.com/pipermail/kameler/2009-May/000318.html
[4] November wiki engine, http://github.com/viklund/november/
[5] Druid, http://github.com/masak/druid/
[6] Proto, http://github.com/masak/proto/


Don't you think this is counterproductive?

Alias on 2009-05-29T07:59:32


Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo .

This release announcement reads to me as...

"We've released the new version of Rakudo. Don't use it. If you're sophisticated enough to have and use git, pull from version control, set up a compilation environment, compile everything yourself, well THEN you can try Perl 6."

If people are interested in Perl 6, is it really SO bad that they are running 1-4 weeks behind the bleading edge? I appreciate you want to encourage people to get more involved, but discouraging people from uses the official releases seems a bad way to do it.

Why bother doing releases at all? You could just as easily just do a monthly report.

Re:Don't you think this is counterproductive?

chromatic on 2009-05-29T10:55:58

If people are interested in Perl 6, is it really SO bad that they are running 1-4 weeks behind the bleading edge?

No, but they're probably missing out if they're a week behind the bleeding edge. The pace of development can be astounding. Ask anyone who's used it this year.

Why bother doing releases at all?

So that code regularly reaches a wider audience of users and potential testers and contributors.

So that people don't have to track trunk.

So that people have a regular stable distribution of Rakudo at regular intervals.

So that the developers have an incentive to keep the code stable, the tests passing, and the distribution releasable.

So that the developers can demonstrate regular, sustainable progress.

So that packagers can make it available to users who might not be able to compile it themselves.

So that developers have an incentive to work in small pieces that don't drag on from month to month.

So that the pace of development -- which we've observed to increase dramatically since adopting monthly releases -- can continue.

Because making and meeting commitments is central to serious software development.

Because unreleased code effectively does not exist, at least from the point of view of potential users.

Re:Don't you think this is counterproductive?

mpeters on 2009-05-29T12:03:31

I'd add one more to this list.

+ So developers can get practice at making releases before people start to depend on them for critical work.

Re:Don't you think this is counterproductive?

chromatic on 2009-05-29T17:17:31

I forgot that one; thank you. It's more important than my omission makes it sound! If making a release is so easy and boring that any of a dozen people can do it with an afternoon's notice, any of a dozen people can make a release to fix a critical bug. We all hope that's not necessary, but we can spend our time focusing on the important part of that process.

Re:Don't you think this is counterproductive?

pmichaud on 2009-05-29T21:39:47

In addition to all of the reasons chromatic gives, I'd add:

* We'd like to avoid getting bug reports and questions about things that were fixed 1-4 weeks prior.

* Application developers often like to target releases instead of trunk for their distributions.

* Many people still believe the myth that Perl 6 is vaporware and will never exist/be finished/be released/etc. The best response to that myth that I can offer is a steady stream of regular releases showing measurable progress towards the goal.

----

With all of the above said, we are nearing the point where I think it's reasonable for people to work from releases instead of trunk, and the release announcement text will likely change soon to reflect that. However, as of the May release we weren't there yet, and as far as I'm concerned we aren't there until we have a truly installable Rakudo. As I noted in another thread [1] Parrot really didn't make that feasible for us until just this week.

[1] http://use.perl.org/comments.pl?sid=43077&cid=68841

Alias, I know you got a bit burned last Fall while trying to create an installable version of Parrot/Rakudo last, and all I can offer is that I've been harping about Parrot's installation issues since long before that. It's only within the past couple of months that we've seen real progress on that front.

----

Ultimately I think the primary reason for regular releases is because it forces us to regularly evaluate our progress, so that we can recognize our successes and bring attention to our shortcomings. Or, in agile development terms, we would say that the regular releases set the rhythm of our development, and short release cycles are conducive to better planning and execution.

Or in the long tradition of open source: "Release early, release often".

Pm