Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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'

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

      I don't disagree with anything you say. Heck, I agree with it.

      But

      I tried it. This is me. I have made m

      • 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 sense if dev and maint are relatively in sync. The further ahead dev gets, the more likely that you have to major work to back port a patch.

        Now it seems to me that doing regular dev releases is MUCH less of a burden that doing regular maint releases. I would hypothesize as well that regular dev releases would make it eaiser for maint to stay synced themselves. As smaller dev releases would mean more major versions, and more major versions would mean that the bleading edge would tend to be closer in terms of code to its predecessors, which in turn should reduce the back port burden of important fixes.

        So I guess while I am not going to argue with you about the burden of our current processes, its not clear to me that it isn't a self fulfilling prophecy. There would be no reason to do heavy work in a maint track if the dev track was moving faster.

        Personally Im inclined to think we could accelerate our dev releases a LOT. In fact I think one is long overdue already. Although I know perfectly well how busy Rafael is and that rolling a release right now is probably not something he really wants to do I am somewhat of the opinion that we should make sure that we have all the major platforms passing test for a few days and announce 5.11.1 as soon as we can. And then do our best to announce 5.11.2 soon after. Who cares if that means that we do a LOT of minor releases in the 5.11 line. At some point or another well decide its good enought to go out the door, and we wont be talking about maintaining 5.10 well be talking about maintaining 5.12.

        Anyway, I guess my point is that making the caboose more efficient isnt going to make a train faster. Making the engine go faster will. And we /can/ make the engine go much faster in dev if we choose. Pretty much as simply as saying "today is 5.11.1 day". Its a blead release, who cares if it breaks here and there. Thats what they are for.

        Would I be correct in thinking that leaving the quality of the latest blead aside that to release 5.11.1 is a matter of creating a tag, rolling and uploading a CPAN bundle and sending out an email?

        Yves

        • Answering the easy bit:

          Would I be correct in thinking that leaving the quality of the latest blead aside that to release 5.11.1 is a matter of creating a tag, rolling and uploading a CPAN bundle and sending out an email?

          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 maintenan