NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Straw man (Score:2)
I don't think chromatic is proposing that Perl start break back compat willy nilly. He's been quite clear that he wants to see Perl on a time-based release cycle with published deprecation schedules.
Imagine if Perl release 4 times a year. Then if there was a desire to deprecate something, a release could say "feature X will be removed after 6 more releases, 18 months from now".
That seems pretty reasonable.
Furthermore, no one out there is jumping from 5.6 to 5.10 without some serious testing. Even with Perl'
Straw men lack JFDI (Score:2)
I don't disagree with anything you say. Heck, I agree with it.
But
I tried it. This is me. I have made m
Re: (Score:1)
I've been watching how some other projects manage this kind of stuff, and I have a few thoughts.
First, you were doing maint releases, and backporting from dev into maint. I dont think that many projects have high frequency maint releases, in most projects maint releases are instead "just enough for the release to not be a problem" and only made as absolutely necessary. If a project has high frequency releases its at the bleading edge not in maint.
Second, IMO backporting from dev to maint AT ALL only makes
Re:Straw men lack JFDI (Score:2)
Answering the easy bit:
No, not just that. What really distinguishes a release from a mere developer snapshot is that a release has a perldelta file - a summary of the changes between the previous release and this release.
(And what distinguishes a maintenance release from a developer release is that in a maintenance release we try very hard not to have anything regress, whereas a developer release is "please try this, and tell us what breaks")
Reply to This
Parent