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.
  • There's a modest but sustainable business model in something similar.

    I still disagree that the impact of the change should determine the deprecation cycle length. The point of having a documented support policy is to remove all of the silly Internet body part measuring contests from project management.

    • The trouble is that the more a feature is used, the more time involved in porting.

      If the time allowed for deprecation is the same regardless of scale, you end up with some fairly horrid Mythical Man Month style amplification in the cost.

      We already dealt with the pathological case of this with Y2K.

      You had a feature (two digit years) which had an absolute hard limit to fix, was present in all languages across almost the entire history of software development and impacted not just on data but also on code.

      And

      • The trouble is that the more a feature is used, the more time involved in porting.

        To my knowledge, no one has suggested removing tie, no matter how much we'd like to see it disappear. Likewise bless. Yet there are plenty of ways to extend the time between first deprecation and final migration: don't upgrade ever, don't upgrade yet, use a backwards compatibility mode in the interpreter, use a backwards compatibility library, move to Nepal to herd yaks.

        Having multiple incompatible half-hearted ways to do