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

[raiph]

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.

[chromatic]

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.

[raiph]

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.

[Anonymous Monk]

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

You've got to be kidding me and all of us. A question was posted on stability policy for Rakudo. So then a question was asked if Rakudo is mature enough for a backwards compatible release which warrants a support/stability policy

What follows next is Perl 6 developers announcing there is no such thing like a backwards compatible release going to happen any sooner but they need a stability policy regardless. Ask why they would need one when there is no release that could even use it and answers go around arguing strange semantics of stability and support

The fact is you know it pretty well, you don't have a release with you for which you can promise any kind of stability whatsoever. You also know that the monthly releases and star releases of rakudo are basically 'works on my machine' trunk snapshot of the code repo zipped and uploaded.

The purpose of a monthly release is to have a stack of work finished and well supported without breakages to previous releases. With documentation and libraries shipped. Its not a ritual you need to execute in front of a deity every month.

You are not in need of a stability/support policy currently as you don't need it. You don't have a release that you can apply it to.

[Anonymous Monk]

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.

[raiph]

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.

[Anonymous Monk]

Closely following???

Doesn't that sort of prove my point? I don't closely follow core development of any software that I use. Nor does any body who minds his productivity even a little bit. Users use more than dozen pieces of software everyday. Nobody has the kind of luxury and time to afford spending following every small IRC ping going in a channel and then spend hours pondering what that's likely to mean.