Supposed to tag revisions with a version number for a release. So you have version n is the set of revision numbers of various components. But nobody says you have to put the revision numbers in a "version" statement. You can just keep them in a comment
Sent from my BlackBerry® smartphone with Nextel Direct Connect -----Original Message----- From: "Bill Ward" <[EMAIL PROTECTED]> Date: Fri, 11 Jul 2008 14:58:06 To: Johan Vromans<[EMAIL PROTECTED]> Cc: <module-authors@perl.org> Subject: Re: VERSION and VCS On Wed, Jul 9, 2008 at 8:09 AM, Johan Vromans <[EMAIL PROTECTED]> wrote: > The CPAN indexer requires perl modules (and sub-modules) to have a > non-descending VERSION number. RCS/CVS $Revision$ has been invaluable > for that. Not really. If you use RCS/CVS numbers, then you have several problems: 1. Various files in the distribution have different version numbers, so it's harder to be sure a user has the right version of each one 2. Commits made during the course of development get version numbers that do not correspond to a release, so it looks like you have missing releases 3. Major vs minor releases should increment different parts of the version number, and doing that at commit time doesn't match the reality of the release process. Because of these issues I feel it's best to just update the version numbers when a release is made. You might as well do this by hand, since you need to update the README, CHANGES, etc. files at the same time. > Now more and more development is migrating towards VCS that do not > have such a feature (git, svn, hg, ...). Probably a good thing, since it forces people to move away from arbitrary and meaningless release numbers. > What are the alternatives? > > Manually updating the version numbers of changed modules before a > release does not sound appealing to me. I know we like things to be automated, but for reasons I mention above, I think this is really the best way anyway. > I ususally get the advice to build a hook script, etc., but I think > this 'problem' should be dealt with at a non-individual level. If it's going to be automated it would still require the person doing the release to make a choice about the version number, update the CHANGES and README, etc.
