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 even if there was nothing that needed fixing, there was still a fairly big cost just to audit the code and make sure the problem didn't apply.

      The result of this deprecation "perfect storm" was enormous amounts of effort and money which achieved the final result of business as usual and mostly not breaking.

      Nothing we could generate would remotely approach that cost, but that doesn't mean there isn't a cost different between deprecating something that wasn't used a lot (we think) like v-strings or pseudo-hashes, compared to something I'd personally like to deprecate, tie(), that is used a lot (we think).

      There's also a difference between deprecations that we can provide completely or mostly reliable auto-upgrade for (like two to three argument open) vs something that would require more substantial rewriting classes that relied on it (like, say, dropping blessed ARRAY support) as well as their depandants (tieing).

      • 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