Hello,
My opinion on the matter of system generated versions is quite black
and white.
- Versions are not the same thing as revisions.
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
