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.
In reply to Re^5: Perl 6: Managing breakages across Rakudo versions
by moritz
in thread Perl 6: Managing breakages across Rakudo Star versions
by raiph
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |