Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^2: Perl 6: Managing breakages across Rakudo versions

by jdporter (Canon)
on Jul 17, 2012 at 10:32 UTC ( #982197=note: print w/replies, xml ) Need Help??

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

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.

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

Replies are listed 'Best First'.
Re^3: Perl 6: Managing breakages across Rakudo versions
by moritz (Cardinal) on Jul 17, 2012 at 10:49 UTC

      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.

        But if you are not going to break backwards compatibility

        "not breaking backwards compatiblity" isn't on the menu plate at all. The original question was how to manage breaking changes:

        In practice what this means is that we want to minimize the number and impact of any "breakages" that people encounter when using existing code on subsequent releases of Rakudo Star.

        So, the question is not "should we stop to break backwards compatiblity", but "how do we do it while doing least harm to our users".

        I don't think that chosing one release and declaring it "production ready" out of the blue, and not doing any breaking changes is going to work. It's much more realistic to first learn how to handle such changes gracefully, then reduce the number of breaking changes, and if that works well, we can start using a stricter policy.

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://982197]
and the leaves swirl about...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2018-05-28 08:52 GMT
Find Nodes?
    Voting Booth?