in reply to Module version numbers best practice

While I personally like the v-string standard for human-readability, the facts already presented in this thread strongly suggest the dotted-decimal system would find the most widespread use -- and reducing your pre-v5.10 non-core dependencies can only be of benefit.

For personal version control I version everything with a timestamp similar to, but not quite exactly like, ISO 8601, and since almost everything on my system has this, and I have a bunch of tools written which make manipulation of these files very, very easy, I'm disinclined to change my personal standard -- but I also don't expose it to other people unless they are watching me type :-).

Example: P-2013-10-18@1131-Alternate-Universe-Project.docx

I suppose I could bring myself some free weekend to convert all my tools to ISO 8601 and it wouldn't take long to adapt.

I'll have to think on that.

But I think the evidence is overwhelming that the answer to your question is likely to be dotted-decimal.

Replies are listed 'Best First'.
Re^2: Module version numbers best practice (meaning--)
by tye (Sage) on Oct 18, 2013 at 18:38 UTC

    Using dates as version numbers still runs into the problems of trying to assign meanings to version numbers. For example, there was a module on CPAN that went to using the integer part of the version number as the year. And then they didn't notice that they had accidentally used next year until they had already uploaded that version to CPAN. This meant they couldn't release anything new with their desired version number scheme for a long time.

    - tye        

[reply]
      The principles of CM merely require that CIs (configuration items) have a means of identification such that different CIs and different compositions/versions of those CIs be readily distinguished.

      In the case of perl, the CIs are modules whose name distinguishes them apart from other modules and $VERSION distinguishes between the versions of a module.

      Whilst not mandated, it is conventional that the versioning scheme readily supports the determination of the temporal ordering of the individual CI versions. To this end, as has been stated elsewhere, the versioning scheme of choice should follow the above whilst allowing for the nuances of perl in it's interpretation of the version identifier.

      FWIW, my preference is to utilise an ISO 8601 style time/datestamp with all separators removed thus removing any mis-interpretation (pun intended) by perl since all version ids are merely, albeit lengthy, integers whose value specifies when the module was checked in i.e. became repeatable. The use of ISO 8601 c/w epoch timestamping, future proofs the versioning against the epoch roll-over.

      Just my 10 penn'orth

      A user level that continues to overstate my experience :-))
[reply]
[d/l]
      ----------------------------------------------------------------------------------^
      tye is right
      tye is justified

      :-)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom