use Perl Log In
Rakudo Perl 6 development release #17
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? (Score:1)
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.org]
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
Re: (Score:1)
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.
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
Re: (Score:1)
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: (Score:1)
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: (Score:2)
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