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

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

This doesn't fit in to what is the general definition of a support policy/stability policy.

Perl 6 is making this a habit to take well used, defined and understood terms and give them totally different meanings. And then then expect the whole world to relearn those new meanings.

The general definition of a support/stability policy is to define what will be fixed, when it will be fixed, and till how long the fixes will be provided between two 'No going back from once made to public' releases. That's how Perl 5 defines it and all software that is released

I think what you are talking of is number of test cases failed or spec coverage affected with a particular refactoring effort. In that case a stability policy is meaningless. For a programming language, many features depend on each other.

A program has many parts, many that depend on each other. If you say you are breaking a very tiny part of it, in essence you break the whole program Eg: If you break the addition operator, you are likely to break all while loops in a program, that is likely to break nearly everything. Therefore a stability policy for any such non backwards compatible release doesn't make much sense.

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

Replies are listed 'Best First'.
Re^7: Perl 6: Managing breakages across Rakudo versions by Corion (Patriarch) on Jul 17, 2012 at 11:51 UTC
I think the idea is to make Rakudo a viable platform for developing extensions (like, say, LWP6, DBI6, AnyEvent6) for. Nobody will port a library to Rakudo if there is no soft or hard promise of how much breakage will happen how fast. I interpret the call for comments as an attempt to gauge how much interest there is in stability of Rakudo, and/or as an announcement that Rakudo will try to change less radically or less quickly than it did before.	[reply]
Re^7: Perl 6: Managing breakages across Rakudo versions by moritz (Cardinal) on Jul 17, 2012 at 11:59 UTC
This doesn't fit in to what is the general definition of a support policy/stability policy. So, who said we are going to have a support policy/stability policy, and that it doesn't meet the general definition of these terms? Once again, we were asking for feedback on how to manage changes. I think you're reading things that weren't written. If you are a user or a potential use of Rakudo, actual, non-bikeshedding feedback on that topic is very much appreciated. Perl 6 - the future is here, just unevenly distributed	[reply]
Re^8: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 17, 2012 at 13:51 UTC
I will give you a frank feedback on what I think should be the way forward for managing things in Rakudo 1. No more major rewrites, as they break a lot of code and a lot of catching up is required in the months that follow. 2. Implementation for at least one backend complete, which is backwards compatible, has basic libraries and usable documentation. 3. Path towards making Perl 5 and CPAN compatible defined, and planned to achieve over a period of time.	[reply]
Re^9: Perl 6: Managing breakages across Rakudo versions by cavac (Parson) on Jul 17, 2012 at 17:15 UTC
I agree. I speak only for myself here as someone who gets paid to write Perl code. Just give me a Perl6 implementation i can depend on. I need to start writing scripts and modules and ditribute them on CPAN. And i need some reasonable guarantees that i don't have to do major rewrites every few months just to keep my code working. Rakudo doesn't have to be "feature complete" or be "highly optimized". To attract developers (who may write Perl code for a living), it needs to be stable enough that it's worth the (company) time to start writing code for it that it more complex than "Hello World" and more useful than self-test scripts. Stop breaking things because you "need to optimize". Frankly, unless Perl6 gets at least one stable, extensible Interpreter (e.g. not major rewrites every time you feel like it), there won't be a big community writing actual, useful code for it that starts to attract even more developers. Ergo it wont run any code that needs an optimized interpreter... Really, give me something i can show to my boss as a reasonable good choice to implement software with that will run for years, maybe a decade. "I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"	[reply]
Re^10: Perl 6: Managing breakages across Rakudo versions by jdporter (Paladin) on Jul 17, 2012 at 17:22 UTC
Re^11: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 18, 2012 at 20:28 UTC
Some notes below your chosen depth have not been shown here
Re^7: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 17, 2012 at 22:09 UTC
I think what you are talking of is number of test cases failed or spec coverage affected with a particular refactoring effort. No. Eg: If you break the addition operator, you are likely to break all while loops in a program, that is likely to break nearly everything. Therefore a stability policy for any such non backwards compatible release doesn't make much sense. Imagine that Perl 6 and Rakudo have reached the point that it's very unlikely that such a basic problem would occur but might. More generally, issues are much more likely to arise than with a mature product such as Perl 5. If you were writing Perl 6 code that runs under Rakudo, wouldn't you want to know what the Rakudo team thinks about such things? Wouldn't you want to know whether they'd consciously break the addition operator and how much notice you might get if they did, and what happens if it occurs accidentally, and so on? Wouldn't you want to know what explicit commitments they are making in this regard? Wouldn't you want to participate in discussions about this?	[reply]
Re^8: Perl 6: Managing breakages across Rakudo versions by jdporter (Paladin) on Jul 18, 2012 at 01:59 UTC
Wouldn't you want to know whether they'd consciously break ... I might like to know it, but I shouldn't be surprised and wouldn't be heartbroken to learn it.	[reply]
Re^9: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 18, 2012 at 17:54 UTC
I think we all agree with Larry's position: no guarantees of stability: "Until 6.0.0, there is no guarantee of stability. You are all Early Adopters. If you can't figure out how to snapshot a particular version and keep it around, you probably shouldn't be Early Adopting. The whole point of Rakudo * is to give us lots of Early Adopters so we can put lots of final polish onto 6.0.0 as rapidly as possible after that. Don't start asking us to leap across the chasm before we're ready." ~~ Larry Wall, March 2010. That said, stability (contrasted with a guarantee of stability) is still a significant issue for most Early Adopters. So it makes sense to me that the Perl 6 and Rakudo teams are considering how they might best accommodate those who care about stability; and that Patrick was considering writing a document to formalize stability policy (even if that policy starts with "there are no guarantees of stability!"); and that Patrick was asking for input from users and other interested parties about these issues.	[reply]
Re^10: Perl 6: Managing breakages across Rakudo versions by jdporter (Paladin) on Jul 18, 2012 at 18:11 UTC
Re^8: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 18, 2012 at 04:47 UTC
If you are guaranteed to break stuff(which is no backwards compatibility) a stability policy has little meaning. I cannot imagine anyone, breaking something for just fun. I know there are valid reasons why anybody would break anything. If you want to discuss about a stability policy you must first work towards a backward compatible release	[reply]

In Section Meditations