> -----Original Message----- > From: Jonas Brømsø Nielsen [mailto:jona...@gmail.com] > Sent: Sunday, September 13, 2009 2:51 PM > To: dhu...@hudes.org > Cc: module-authors@perl.org > Subject: Re: how to set $VERSION throughout distribution > > Hello, > > My opinion on the matter of system generated versions is quite black > and white. > > - Versions are not the same thing as revisions.
Indeed. I also don't like $VERSION = localtime() stuff like $VERSION = 20090913.foo thingies. Just nonsense. > A known problem with using auto-inserted values of different formats > is that it makes it hard to migrate your code from one SCM to another. > I have tried this with CVS and SVN previously. What other surprises > exist in a SVN/GIT integration I have no idea. > > Revisiting Jonathans original list: > > 1) Don't bother putting $VERSION anywhere except the main module > 2) Put a different $VERSION in each module, depending on when that > module itself changes > 3) Put the same $VERSION in each module, matching the distribution and > the main module > > I am a 2'er myself. I handle all version numbers manually, I use > version numbers for indicating changes, so POD changes and minor bug > fixes, might go unnoticed a part from a mention in the Changes file. > Where all major changes are reflected in the version number of a > package. > > For sub-packages in distributions I use the same policy. I have often > experienced the a package is lifted out of a distribution, so become a > distribution of it's own, so the version follows the unique > identification of a package. Since the package whether distributed on > it's own or as part of a larger distribution is a unique component, is > locatable in @INC. > > As for a package renaming I would reset the version to be an initial > release, I guess. > > I learned one lesson based on feedback from a user and that was that > the distribution number should be reflected in the main package > identified by the build file an example from Workflow: > > dist_name => 'Workflow', > dist_version_from => 'lib/Workflow.pm', > > The distribution started out having a version number only defined in > Build.PL, so tracking what distribution was installed based on > evaluation of Workflow.pm was somewhat hard. > > For version numbers I like the 3 part version numbering, but that is > just a matter of taste, the important thing is that version numbers > are sequential. > > Just my 5 cents, > > jonasbn > > On 13/09/2009, at 02.39, Dana Hudes wrote: > > > If you are working with a perfile VCS such as sccs, rcs, cvs or svn > > then each file has it's own revision # and rightly so because that's > > how the author is managing code > > > > OTOH if one uses Mecurial then a commit of a changeset has a # and > > its the changeset you track so you use that #. This still leads to > > different files with different #s but that's ok since you have all > > the same #s for a change set > > > > Sent from my BlackBerry® smartphone with Nextel Direct Connect
