in reply to Re: Don't use 5.6.N (why)
in thread Don't use 5.6.N

I would disagree with this. I feel that saying "use 5.006;" when you haven't tested with older Perls means "I am only willing to support 5.006 or higher". I had a big internal debate about this with DBM::Deep and decided that I simply didn't have the time to worry about 5.005_03 and the like. So, I put it in and that freed me up to use features that are 5.006+ with impunity (such as 3-arg open, warnings, our, and the like). This was a deliberate choice that was based on non-code-related factors.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^3: Don't use 5.6.N (why guess?)
by tye (Sage) on Oct 17, 2007 at 17:14 UTC

    No, "use 5.006;" doesn't say much of anything. Do you have some reason you only want to document your reasons in this obscure node that nobody will find? You've said you already have a code template, so just add a comment to your template.

    Update: I don't see how you are disagreeing with me. You do know that your module doesn't work with 5.006 and you even know why it doesn't (as well as why you chose that route). Unless you are disagreeing that such information should be given to your module's users.

    - tye        

      I think you misunderstood me. I could've made dbm-deep work with 5.0.0, if I'd really wanted to. But, I didn't want to work harder on backwards-compatibility than I was working on features. I have enough problems maintaining OS-compatibility, as it is. So, I chose to put a hard-demarcation in. I could've easily chosen 5.008 instead of 5.006.

      Once that demarcation was chosen, that freed up certain features for use. But, the line wasn't chosen for the features - it was chosen for the personal sanity. And, "use 5.006;" says exactly what it needs to say "This software is only going to work with this version or higher".

      Now, granted, this discussion is starting me down the road of "I need to document the why behind this assertion in the POD" and I now will. Sometimes, my good friend, you make me think too much! :-)


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

        No, I didn't misunderstand. Neither warnings.pm nor our is ever a requirement. And in other threads I've even explained why I consider doing "use warnings;" in a module to be a mistake and why use vars is better than our.

        The new features are usually quite minor improvements (and often mixed blessings). Though they are often touted (usually by their inventors and usually before anyone has had any time to really use them) as being profoundly important and people (understandably) tend to believe the standard documentation (written by the inventor of the new feature) and so this touting spreads.

        But the further back you go, the larger the collection of minor features is and the more work it is to forego the sum total of these minor improvements.

        Please at least include next to your "use 5.006;" line a pointer to the section in your POD that explains it (when you write it). And consider doing "BEGIN { require 5.006; }" so automated tools can better parse the failure reason.

        - tye