Re: Version Numbers
On Thu, Jan 08, 2004 at 07:46:04PM -0800, David Wheeler wrote: Hi All, What's the consensus on the version numbers to give to different modules in a CPAN distribution? I've traditionally only incremented the main module in a distribution and any modules that have been changed since the last release. But this means that I have modules in a single distribution with different version numbers. Other CPAN authors have omitted version numbers from all but the module that names the distribution. Still others have made all of the modules in a single distribution have the same version number. So, what do people like or prefer, and why? Is there a consensus on this? If so, what is it? I can't comment on consensus, but I think that for clients of the module, what they really want to know is the module number as found on CPAN. Even if inidividual files have not changed, as they're part of one package, they likely interoperate and so their behaviour will change anyway. To achieve this, I export $VERSION from the main module (the one named in Makefile.PL to retrieve the version from), and import it in the remaining modules. It'll break if the module is installed by hand in parts, but then I figure that if you do that, you're on your own anyway. For the rest of the time, it works nicely to ensure that I don't get caught out by forgetting to update the numbers in individual files. Mx.
Re: Version Numbers
David Wheeler wrote: So, what do people like or prefer, and why? Is there a consensus on this? If so, what is it? I manually give the main module in a distribution a real version number such as 2.00, 2.01, and so on. Naturally this changes on every release. All the other modules in a distribution have a version number built automatically from the CVS revision. This changes only when the source file changes. $VERSION = sprintf(%d.%02d, q$Revision: 1.23$ =~ /(\d+)\.(\d+)/); I think it's a good idea for every module to have a version number, even if they are very rarely used. If possible, don't change version numbers of sub-modules between distributions unless they have changed. That way it is easy to tell at a glance that versions 2.10 and 2.11 of the Foo::Bar distribution, both use the same version 3.14 of the Foo::Bar::Magic::Helper module, for example, without having to mess around with diff. A
Re: Version Numbers
Elizabeth Mattijsen said:
At 19:46 -0800 1/8/04, David Wheeler wrote:
What's the consensus on the version numbers to give to different
modules in a CPAN distribution? I've traditionally only incremented
the main module in a distribution and any modules that have been
changed since the last release. But this means that I have modules
in a single distribution with different version numbers. Other CPAN
authors have omitted version numbers from all but the module that
names the distribution. Still others have made all of the modules in
a single distribution have the same version number.
I prefer the latter.
I do too, though Andy's point is well made. I tend to think of the
distribution as a single entity rather than a collection of modules.
Though provided each module has a version number I don't think there is a
problem.
I have an update script that forces me to go
through all of the module files of a distribution. It forces me to
check things whenever I start a new version.
Ooh. Too much work! Here's the relevant parts of a Makefile.PL showing
how I automate that. Whenever I use an internal module I always specify
the version and that is automatically updated too, as is the version
number and date in the pod. (This will probably get mangled by my mailer
- the real thing is on CPAN of course.)
use ExtUtils::Manifest maniread;
my $Version = 0.3206;
my $Date = 8th January 2004;
my @files= sort keys %{maniread()};
my @versions = grep { $_ ne Makefile.PL } @files;
sub MY::postamble
{
qq[
SET_VERSION = \$(PERL) -pi.version \\
-e 's/(^\\s*(?:our\\s+)\\\$\$VERSION =
)\\d+\\.\\d+(;)/\$\${1}$Version\$\$2/;' \\
-e 's/(Version )\\d+\\.\\d+( - ).*/\$\${1}$Version\$\${2}$Date/;' \\
-e 's/(Devel::Cover Version )\\d+\\.\\d+/\$\${1}$Version/;' \\
-e 's/(\\buse Devel::Cover(?:::\\w+)*\\s+)\\d+\\.\\d+/\$\${1}$Version/;'
@versions : Makefile.PL
\t \$(SET_VERSION) @versions
}
So, what do people like or prefer, and why? Is there a consensus on
this? If so, what is it?
I don't think there is a consensus. ;-)
Vive la Difference!
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Version Numbers
* David Wheeler [EMAIL PROTECTED] [2004-01-09 12:37]: So, what do people like or prefer, and why? I don't yet have any modules on CPAN (I do have an ID and plans for it), but I intend to handle this the way Andy does and I also prefer it as a user of modules when authors keep to that practice. It makes sense to distinguish between the versions of the parts of something, ie a distribution or project release, and the version of that something itself. Versioning systems do this as well, for good reasons. I can see an argument for having all files explicitly set to the same version, namely, that it's easy to track which version of the distro/release a particular part of it belongs to. There seems to be no reason that merits omitting or implictly setting the version, and plenty of reasons not to. Probably the best idea that would satisfy all requirements is to explicitly tag everything, or at least the submodules, with two different version numbers - one for their private version, one for the version of the distribution they're distributed with. Treatmennt of the latter is not absolutely obvious though, as it's a potential 1:n relation for all the parts of the distribution (even for the main module, in case of brownbag fixes in one of the submodules). And of course the obvious problem is that there's no established convention for the existence and naming of a distribution version tag. On the other hand, maybe we don't even need to establish such a convention. From the point of view of a program, the distribution version really doesn't matter; if the version of a submodule is important, then what the program is concerned with is having a certain version of that submodule available. Which distribution version it was packaged with is really less interesting. So a notice along the lines of This file was packaged with the Foo-Bar-0.42 distribution in the POD should suffice. I think that's my conclusion; version the submodules individually and have a notice in POD to reflect the version of the distribution they belong to. Thanks for the food for thought. :) I don't know if anyone will agree with my arguments, but I hadn't thought about this in detail before, and your question was a nice opportunity to mull over the issues. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Version Numbers
At 12:15 +0100 1/9/04, Paul Johnson wrote: Elizabeth Mattijsen said: I have an update script that forces me to go through all of the module files of a distribution. It forces me to check things whenever I start a new version. Ooh. Too much work! Here's the relevant parts of a Makefile.PL showing how I automate that. Whenever I use an internal module I always specify the version and that is automatically updated too, as is the version number and date in the pod. (This will probably get mangled by my mailer - the real thing is on CPAN of course.) Under what name? Devel::Cover? Liz
Re: Version Numbers
On Fri, Jan 09, 2004 at 08:49:59AM +, Andy Wardley wrote: I think it's a good idea for every module to have a version number, even if they are very rarely used. If possible, don't change version numbers of sub-modules between distributions unless they have changed. That way it is easy to tell at a glance that versions 2.10 and 2.11 of the Foo::Bar distribution, both use the same version 3.14 of the Foo::Bar::Magic::Helper module, for example, without having to mess around with diff. I think it's a good idea too, because it makes life easier trying to keep track of files in dual-life modules. The other important bit is to actually change the version number if anything in the file changes. But I'm biased. :-) Nicholas Clark
Re: Version Numbers
* Elizabeth Mattijsen [EMAIL PROTECTED] [2004-01-09 14:11]: I think the packaged with distribution is a _very_ nice extra addition that could be automatically handled with Devel::Required. Laziness good. :-) Something like: =head1 DISTRIBUTION INFORMATION This file was packaged with the Foo-Bar-0.01 distribution on Friday January 9th, 2004 on 14:12 CET. The date is a nice touch. I'd definitely include the file's private version in the POD though. It might be better kept under a more generic heading such as VERSION then. Although DISTRIBUTION INFORMATION would still be appropriate if maybe it's phrased like This file is Foo::Bar::Baz 0.07, packaged with the [...] or something. At any rate, regardless of my preferences automating this would be helpful whichever form the POD takes. Maybe it should be configurable; either fully and freely or as a choice between predefined forms. But maybe uniformity is more desirable. I have no arguments and so no firm opinion on that. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Version Numbers
At 15:00 +0100 1/9/04, A. Pagaltzis wrote: * Elizabeth Mattijsen [EMAIL PROTECTED] [2004-01-09 14:11]: Something like: =head1 DISTRIBUTION INFORMATION This file was packaged with the Foo-Bar-0.01 distribution on Friday January 9th, 2004 on 14:12 CET. The date is a nice touch. I'd definitely include the file's private version in the POD though. It might be better kept under a more generic heading such as VERSION then. Although DISTRIBUTION INFORMATION would still be appropriate if maybe it's phrased like This file is Foo::Bar::Baz 0.07, packaged with the [...] or something. At any rate, regardless of my preferences automating this would be helpful whichever form the POD takes. Maybe it should be configurable; either fully and freely or as a choice between predefined forms. But maybe uniformity is more desirable. I have no arguments and so no firm opinion on that. Hmmm... now there are two catches to implement this in Devel::Required. - Is Devel::Required still a good name then? - How will I be able to distinguish between a developer and a user situation when Makefile.PL is run? Liz
Re: Version Numbers
* David Wheeler david at kineticode.com [2004/01/08 19:46]: What's the consensus on the version numbers to give to different modules in a CPAN distribution? Lately, all the code I write has had two version numbers: $VERSION and $REVISION. I keep $VERSION up to date with the version number of the distribution, and $REVISION is updated using CVS's magic handling of $Revision$, as Andy showed. (darren) -- One cannot make an omelette without breaking eggs -- but it is amazing how many eggs one can break without making a decent omelette. -- Professor Charles P. Issawi pgp0.pgp Description: PGP signature
Re: Version Numbers
* Elizabeth Mattijsen [EMAIL PROTECTED] [2004-01-09 15:15]: Hmmm... now there are two catches to implement this in Devel::Required. - Is Devel::Required still a good name then? I think not, but I have not the slightest clue what to propose. All I know is it's dealing with versions, so maybe something in that direction is appropriate. - How will I be able to distinguish between a developer and a user situation when Makefile.PL is run? The obvious answer is you defer to the Makefile, which knows the difference between the all and dist targets. The problem is.. well.. you have to hack the Makefile generation. Yuck - yuck! Not my idea of fun. At all. *shudder* Module::Build would be a clean solution but I don't believe you want to exclude EU::MM users from using your module. I guess you need to introduce another parameter to Makefile.PL? There's nothing else I can think of. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Version Numbers
On Thu, 8 Jan 2004 19:46:04 -0800, David Wheeler wrote: What's the consensus on the version numbers to give to different modules in a CPAN distribution? [snip] Still others have made all of the modules in a single distribution have the same version number. This is the practice I have followed in my 2 CPAN distributions (List-Compare and Data-Presenter) and I developed a script which goes through all files in a distribution (i.e., manifests and readmes as well as .pm files) and prompts me to increment both version numbers and dates. But I started to do this not out of any firm belief that all modules in a distro should have the same version number, but simply because previously only my main module had a version number; packages/sub-modules called internally lacked a version number. I realized that this was not good and made a somewhat arbitrary decision to use the same $VERSION throughout. Some of the solutions proposed by others may work better for their modules, particularly if they're using CVS. Jim Keenan
Re: DBIx::Recordset : how to make 0.25 the most recent version?
On Thu, 08 Jan 2004 05:59:51 -0500, Terrence Brannon [EMAIL PROTECTED] said: 1- I uploaded version 0.25 of DBIx::Recordset to supercede to 0.24 release as I am the new maintainer 2 - CPAN.pm showed 0.24 as the new release so I asked Gerald to edit the metadata on PAUSE for DBIx::Recordset, to turn it over to me 3 - even after the metadata change, the most recent version is listed as 0.24 Please visit PAUSE and click on Force Reindexing. That should explain itself and take you where you want. If not, please let us know. Regards, -- andreas
Re: Version Numbers
On Jan 9, 2004, at 6:08 PM, A. Pagaltzis wrote: You should probably look at Liz' Devel::Required module first, even though it doesn't yet(!) do what you've sketched -- and particularly because: Yeah, right...in my spare time! :-) Yeah, but I use Module::Build, not ExtUtils::MakeMaker. But maybe I can pilfer some code. A patch is probably a better investment of your time than a from-scratch attempt. See above. Cheers, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
