use Perl

• The problem with that mechanism... (Score:1)

  by Alias (5735)

  Is that many people are trained (and thus find it "intuitive") that the first number communicates the "stableness" of the module.
  
  0.xxxx vs 1.xxxx etc
  
  What does a date mean? What information can be gleaned "at a glance".
  
  
  • Re:The problem with that mechanism... (Score:2)

    by schwern (1528) on 2007.12.17 20:36 (#59499) Homepage Journal

    Is that many people are trained (and thus find it "intuitive") that the first number communicates the "stableness" of the module.

    
    You're right, and it's a false connection. In fact, 1.0 is often the LEAST stable, you want 1.01. And then everyone has different ideas about what an integer version jump should mean, case in point this comment about Text::Metaphone 2.0 [perl.org].
    
    And then does that mean *API* stability or *bug* stability?
    
    For me the 0.x -> 1.x jump is API stability and future integer jumps usually coincide with major internals reworking. Test::Harness 1.x -> 2.x was moving the parsing into Straps and 2.x to 3.x was the change to TAP::Parser. MakeMaker 5.x to 6.x was my takeover and major internals refactoring. But that's just me. Everyone's got a different idea.
    
    Since version numbers are a poor way to convey stability, and people have been trained that way, I will simply stop using version numbers that people might confuse with stability declarations. I plan to add something to META.yml to explicitly declare stability.

    What does a date mean? What information can be gleaned "at a glance"?

    
    The release date, that's all. What can be gleaned is that when your installed release came out in 2002 and the latest release is from 2007... maybe you should look into upgrading.

    Reply to This

    Parent

    • Re: (Score:2)

      by drhyde (1683)

      A good compromise would be to use X.YYYYMMDD then, where X increases whenever the API changes incompatibly.
      • improving software version schemes (Score:1)

        by markjugg (792)

        I like the spirit of the original post, but agree with drhyde that API stability changes are also important to communicate.
        
        Too often cruft is added and software becomes more complex in the name of "backwards compatibility". I've done it.
        
        Something like the use only [cpan.org] system seemed like a good idea to address this, but it never caught on, and I admit to not adopting myself.
        
        Perl 6 has some related features built-in, but it will be a while still before that's ready for production use...
      • Re: (Score:2)

        by schwern (1528)

        Problems with that.
        
        1) 8 decimal places edges into the realm of floating point error.
        
        2) It has the string vs float problem.
                2.20071220 is different from "2.20071220".
                Combined with #1 this can be trouble when comparing versions.
        
        3) The meaning of X is still arbitrary. Even if the user realizes that it
                indicates stability, specifically API stability, is 3 incompatible with 2?
                Which ever answer yo
        • Re: (Score:2)

          by drhyde (1683)

          wrt floating point error, just chop the 20 off the year. I'm gonna be dead by the time it matters, so I don't care :-)