Module version numbers best practiceby hippo (Canon)
|on Oct 18, 2013 at 16:08 UTC||Need Help??|
hippo has asked for the
wisdom of the Perl Monks concerning the following question:
The time has come to publish a module on CPAN (hurrah!) and in cleaning up the code in advance of publication the need has arisen to choose a version number system. Unfortunately the documentation which I have found (much of which is well out of date) is unclear and/or contradictory so I humbly ask for your thoughts and advice.
The documentation for version suggests that there are only two options, the dotted decimal (1.23) and the v-string (v1.2.3). I would like my module to be useful to the widest extent and this prejudices me against the latter because it requires another non-core dependency in pre-5.10 versions of perl. Of course this is a minor point but if there's no real advantage to v-strings why make extra work?
The older docs here at PM such as Simple Module Tutorial seem to be happy with dotted decimal (but see the first subthread for discussion on this). The (slightly) more recent Josť's Guide for creating Perl modules is equally happy with it and describes the traditional 1.23_45 format for dev releases which seems to me to be both widespread and sensible.
So, the question is this. Is there anything inherently problematic with dotted decimal either now or that could be reasonably foreseen? Thanks for any advice you can give.
Update and Summary
Thanks to everyone who responded - your advice is much appreciated. There seem to be reasonable levels of support for both date-based versions and traditional dotted-decimal and some lesser support for v-strings.
I've decided to go for dotted-decimal in this particular case for reasons of simplicity, backwards compatibility and legibility. The expectation (rightly or wrongly) is that development of the module won't be rapid so two digits will suffice for minor versions (eg. 1.01_01) which I think is the best compromise in the circumstances.
Finally, thanks to admiral_grinder who makes an excellent point. I too have been caught out by this in third-party bundles in the past and will therefore strive to avoid such confusion in my own code.