Re: Module and package version numbering
What I'm moving towards is what SVK does. It has an SVK::Version module which simply defines $SVK::VERSION. Then in other modules you can write: use SVK::Version; our $VERSION = $SVK::VERSION; That way it will be picked up by most $VERSION scanners. See my post further up about syncronised versions. In that context, I think this is a bad idea. Old modules that should no longer be loaded will display the correct version and can't be detected. Assuming that SVK is using Class::Autouse (which I know it is) and is using the recursive loaded (which I don't know about) then SVK is behaving incorrectly in this regard. Adam K
Re: Module and package version numbering
David Cantrell wrote: Adrian Howard wrote: On 18 Apr 2005, at 17:03, David Cantrell wrote: Number::Phone::UK::Data - no version, this is where the .0004 comes from though. It has no version number because the entire file is generated from a *really* dumb script I agree with Schwern that there is no correct :-) However, if it were me, I would generate a version number along with the module (seeded from the version number of the generating script.) The script that generates it doesn't change. The data that it mangles into a module is the bit that changes. I don't know if this applies, but you may want to split the data out into a seperate package and implement it using something like Data::Package to abstract the data storage from the use of it. Some time down the line I'm hoping to add Data::Managed to the Data::Package dist, which will let installing packages register that they are a data package that needs to be updated at intervals. Data::Managed would come with a script to update all registered data packages on a regular basis. Just a thought. I'm getting sick of seeing super-sized perl modules in CPAN that are nothing more than data showhorned into perl structures. The worst examples are things like the Arial font in PDF::API2 included in the form of a 2.8meg Perl module. Data::Package should provide a useful way to abstract out the data from it's use. ugh Adam K
Re: Module and package version numbering
I've yet to read anything /really/ convincing for either side - so I'd do whatever you're comfortable with myself. In my case I tend to use synchronised version numbers. For big APIs (20+ classes) I often use Class::Autouse to recursively load them. If two subsequent versions of the dist change the name of a module from Foo::Bar to Foo::Baz, then the CPAN installer doesn't remove the old one, instead it keeps them both. By using synchronised versions to describe a set of modules, I can write a fairly simple test script that recursively autoloads all the modules, and then checks all the versions are the same. This ensures that I didn't accidentally load in an old/incorrect/broken module I wasn't expecting. Of course, this ONLY applies for very large APIs. In things where you are manually using each child module this won't matter so much (although I do it from habit anyways). So, to add a specific recommendation When using automated recursive module loading, you should keep the version numbers the same Adam K
Re: Module and package version numbering
Adrian Howard wrote: On 19 Apr 2005, at 11:40, David Cantrell wrote: The script that generates it doesn't change. The data that it mangles into a module is the bit that changes. Can you add a version number to the data? Yep, did that last night. It's (eg) 1.20050420. I dug through my mail and found that it was very large values, not very long values, that were now forbidden. -- David Cantrell
Re: Module and package version numbering
Adrian Howard wrote: On 18 Apr 2005, at 17:03, David Cantrell wrote: Number::Phone::UK::Data - no version, this is where the .0004 comes from though. It has no version number because the entire file is generated from a *really* dumb script I agree with Schwern that there is no correct :-) However, if it were me, I would generate a version number along with the module (seeded from the version number of the generating script.) The script that generates it doesn't change. The data that it mangles into a module is the bit that changes. So I'll take the suggestion of putting MMDD into a version number. But then wasn't there some issue with CPAN.pm not liking very long version numbers, after Randal went and did his silly automagic daily module stunt? -- David Cantrell
Re: Module and package version numbering
On 19 Apr 2005, at 11:40, David Cantrell wrote: [snip] The script that generates it doesn't change. The data that it mangles into a module is the bit that changes. Can you add a version number to the data? So I'll take the suggestion of putting MMDD into a version number. But then wasn't there some issue with CPAN.pm not liking very long version numbers, after Randal went and did his silly automagic daily module stunt? I guess you could do something like Y.YYYMMDD - I can't see that causing problems. If I couldn't add a version number to the data I'd probably rip out the revision number of the last change of that file from subversion (or whatever your local SCM is). Adrian
Module and package version numbering
My apologies if this is the wrong place to ask, but it seems like the least-worst option of all the perlish lists I'm on :-) I'm not sure if I'm using version numbers properly. For example, I recently released a package Number-Phone-1.3004 to the CPAN. That number comes because it contains the third significant change to the code, and the fourth significant change in the accompanying data for that release of the code. Inside that package are the following modules: Number::Phone - version 1.2 Number::Phone::UK - version 1.3 Number::Phone::Country - version 0.5 Number::Phone::UK::Data - no version, this is where the .0004 comes from though. It has no version number because the entire file is generated from a *really* dumb script The version numbers for the three modules which have 'em are unchanged since the previous 1.3003 release. The imminent 1.3005 release, however, will bump Number::Phone::Country's version up a notch as I fiddle with the data embedded in it. So I have two questions: 1) Am I correct to seperate the package version (1.3004) from the versions of the several modules contained therein - and if not, where should the package version number come from? and 2) Am I breaking anything? -- David Cantrell
Re: Module and package version numbering
On Mon, Apr 18, 2005 at 05:03:42PM +0100, David Cantrell wrote: 1) Am I correct to seperate the package version (1.3004) from the versions of the several modules contained therein - and if not, where should the package version number come from? and There is no correct here. As long as each .pm file with a public interface has a version number and that number increases every time its changed you're fine. If you want to sync them... well Andreas is currently working out how to best do that and not break the indexer. 2) Am I breaking anything? Nope. Though I'd slap some sort of version on the Number::Phone::UK::Data. If you generate it from the Makefile.PL use the distribution number. If its generated somewhere else that can't easily get at the dist number use an ISO date (20040418) or read it from the META.yml.
Re: Module and package version numbering
On 18 Apr 2005, at 17:03, David Cantrell wrote: [snip] Number::Phone::UK::Data - no version, this is where the .0004 comes from though. It has no version number because the entire file is generated from a *really* dumb script [snip] I agree with Schwern that there is no correct :-) However, if it were me, I would generate a version number along with the module (seeded from the version number of the generating script.) Personally I prefer separate version numbers per-module, but some people don't. I've yet to read anything /really/ convincing for either side - so I'd do whatever you're comfortable with myself. Cheers, Adrian
Re: Module and package version numbering
Michael G Schwern wrote in perl.qa : On Mon, Apr 18, 2005 at 05:03:42PM +0100, David Cantrell wrote: 1) Am I correct to seperate the package version (1.3004) from the A small correction -- 1.3004 would be the distribution version, (not mentioned as $...::VERSION in any package).
Re: Module and package version numbering
On Apr 18, 2005, at 12:50 PM, Adrian Howard wrote: Personally I prefer separate version numbers per-module, but some people don't. I've yet to read anything /really/ convincing for either side - so I'd do whatever you're comfortable with myself. I used to do it per-module, but then I kept forgetting, between releases, which modules I had updated since the last one, or which ones I'd changed and needed to update again. So I switched to making all of my modules have the same version number, and I just use a script to update them all at once. http://www.justatheory.com/computers/programming/perl/ increment_version.html Regards, David
Re: Module and package version numbering
On Mon, Apr 18, 2005 at 02:00:23PM -0700, David Wheeler wrote: On Apr 18, 2005, at 12:50 PM, Adrian Howard wrote: Personally I prefer separate version numbers per-module, but some people don't. I've yet to read anything /really/ convincing for either side - so I'd do whatever you're comfortable with myself. I used to do it per-module, but then I kept forgetting, between releases, which modules I had updated since the last one, or which ones I'd changed and needed to update again. Ditto. And the old CVS per-file revision number trick doesn't work with modern versin control systems. Subversion revision numbers are project wide. Using SVK means revision numbers are different for everybody's checkout. darcs doesn't even have revision numbers. What I do now is run an svk diff -rrevision of last release -s | grep .pm before release to see what .pm files have changed since the last release and increment by hand. Its clunky and time consuming for large dists such as MakeMaker. What I'm moving towards is what SVK does. It has an SVK::Version module which simply defines $SVK::VERSION. Then in other modules you can write: use SVK::Version; our $VERSION = $SVK::VERSION; That way it will be picked up by most $VERSION scanners. The problem is the PAUSE/CPAN indexer will NOT run code. It just uses a regex. So it will not figure out the version above. The solution for this looks like duplicating the per .pm version information in the META.yml file which is what I think Module::Build already does via provides. I don't know what the state of the PAUSE indexer is in reading the META.yml.
