Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.

  • 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 [] .

    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

    • 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.

      • 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.

        • 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.

      • 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