http://www.perlmonks.org?node_id=982180


in reply to Perl 6: Managing breakages across Rakudo Star versions

I don't get it.

I always thought that Rakudo or any other Perl 6 implementation is currently in a stage where they would like to break things and continue that until they announce a release that will remain compatible with any release further. In fact I thought that was explicit goal of Perl 6 to break compatibility once and once only and fix as much as its possible with that jump.

Besides if this is not supposed to be a production release then why even bother? Because until you announce one, you always have the luxury to experiment, break, fix and add new stuff till as much as you can.

Or should we take this is as an Indication that a Production release is imminent in the very near future and a support policy is being drafted for it?

  • Comment on Re: Perl 6: Managing breakages across Rakudo versions

Replies are listed 'Best First'.
Re^2: Perl 6: Managing breakages across Rakudo versions
by jdporter (Paladin) on Jul 17, 2012 at 10:32 UTC

    Concur 100%. Until there's a production release, who gaff what the stability policy is? At this stage of the game, you shouldn't be thinking about stability at all.

        Well by all means, that is a great thing

        But if you are not going to break backwards compatibility, that more or less counts as a production release, because then you are announcing the future releases are going to be feature additions and bug fixes but not deprecations and no feature breakage are going to happen

        In that case the original email in which Patrick mentions Perl 6's versioning system of specifying version numbers to denote a set of semantics that remain valid with backwards compatibility stands to apply.

        Anything less than this isn't a stability support policy at all. Because then you are just saying you are going to fix bugs, which you are going to anyway.

        So should we take this a indication for a first backward compatible(No going back after this) Perl 6 release, or more appropriately a production release? In such a case I'm game for a discussion, because that would make a lot of dreams of many people come true.

        Then Perl 6 is in production, whether you (they?) admit it or not. Better to admit it, and re-frame everything, not just the "stability policy".

Re^2: Perl 6: Managing breakages across Rakudo versions
by raiph (Deacon) on Jul 17, 2012 at 19:19 UTC
    I thought that was an explicit goal of Perl 6 to break compatibility once and once only

    Yes.

    if this is not supposed to be a production release then why even bother?

    Imagine you were managing the Rakudo release process.

    There are already Rakudo users and some are using it in production settings. Would you completely ignore their desire for management of breakages just because you aren't ready to make the sort of compatability promises Perl 5 makes?

    Further, imagine that you thought there was a good chance you could ship a release in 2013 explicitly announced as suitable for deployment in production settings. Would you prefer to wait until after that release has been shipped before starting to discuss and develop a framework for handling breakages? Would you discuss it 3 months prior to your estimated final ship date? 6 months?

    Would you do anything to support users who are writing or distributing Perl 6 modules?

    Bridges to other libraries, especially CPAN, are very important. What about supporting those who are interested in completing those bridges?

    The Perl 6 spec includes versioning features (for both modules and the compiler). But they are not yet implemented. Would you ignore interim measures in the hope that those features get implemented in the next few weeks?

    Or should we take this is as an Indication that a Production release is imminent in the very near future and a support policy is being drafted for it?

    If by "very near future" you mean this year, I think there's about zero chance of that. But I've been watching Perl 6 closely for 12 years, and to me it's obvious why some folk have begun to deploy Perl 6 in production settings (it's already sufficiently attractive, despite some big problems, most notably weak documentation and lack of stability.). cf Larry Wall's recent comment about productizing Perl 6.

      I'm all for Rakudo improving the experience of deploying and maintaining serious code, but it's disingenuous to hand-wave away any differences between "some people are doing this with it and they don't mind babysitting their code between releases" and "you should take this seriously because it's ready for deployment like any other mature piece of software you might expect".

      I've been burned before. Rhetorical flourishes and linguistic contortions to redefine away objections won't convince me that I can ship a project built in Rakudo to paying customers (without losing money on support) because people have good intentions now, or Larry wrote a message somewhere.

      When the Rakudo developers meet the commitments they've made and demonstrate that they can continue to meet those commitments, I'll take themthose commitments seriously.

      Edit to add: I mean that last paragraph sincerely. I believe everyone involved is acting in good faith. All I mean is that I'm not going to be an early adopter.

        it's disingenuous to hand-wave away any differences between "some people are doing this with it and they don't mind babysitting their code between releases" and "you should take this seriously because it's and ready for deployment like any other mature piece of software you might expect".

        I agree there's a big difference between the two levels you describe. It's so big there's room for at least one more stage in between, which is what I believe is Rakudo Star's niche.

        When the Rakudo developers meet the commitments they've made and demonstrate that they can continue to meet those commitments, I'll take them seriously.

        As you know, I still take them seriously, as you once did. I believe Patrick's request for comments about such commitments, and concrete steps designed to meet them, are appropriate, sincere, serious and have already been productive.

      Dear Lord!!!

      You've taken Larry's comment totally out of context, I don't think he means there will be a compiler product two or three years from now. He is just saying there are somethings that need to be done in an year or two to make Perl 6 productized in the future

      Secondly for a minute I cannot imagine any serious person using a non backwards compatible language in production settings. I would seriously doubt credibility of such a business. I think you are referring to IRC bots and Rosetta code wiki submitters, which in case their use cases hardly count for production settings.

      Rakudo doesn't have serious users. Nor people who wish to learn it to do useful stuff. That is why backwards compatible release is so important, to bring that seriousness back.

        Whazzup!!!

        Here's the original comment.

        Rakudo doesn't have serious users. Nor people who wish to learn it to do useful stuff.

        So now I know you aren't actually closely following Perl 6 or don't hold yourself to high standards of accuracy in what you write. I acknowledge the likes of sirrobert (to pick a recent example) are few and far between, and that he's as likely to fail as he is to succeed, but having so few users is not the same as having none. Imo a big part of the reason Perl 6 has so few users is that it has a bad reputation that is reinforced by folk such as yourself who are not actually closely following the project yet choose to write untrue negative stuff about the project as if it were fact.