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

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

      • A good compromise would be to use X.YYYYMMDD then, where X increases whenever the API changes incompatibly.
        • 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 you choose, how is the user to know?

          4) It kills the focus on "your shit is old, upgrade" which I like so much.

          I would rather have an explicit mechanism, probably as part of META.yml, to convey stability rather than cram it all into a version number. Also the ability to separate bug stability vs API stability.

          This also has the nice advantage of automated installers being able to warn you. "You're about to upgrade to an incompatible API!" You could also set automatic API upgrade policies.
          • 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 :-)