Re: how to set $VERSION throughout distribution
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
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. 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
Re: how to set $VERSION throughout distribution
On Sep 13, 2009, at 7:36 AM, Shawn H Corey wrote: Jonas Brømsø Nielsen wrote: dist_name = 'Workflow', dist_version_from = 'lib/Workflow.pm', I would be tempted to: dist_version_from = 'lib/Workflow/VERSION.pm', Comments? I thought about that too and rejected it as unnecessary complexity. You still need a $VERSION in Workflow.pm anyway or else Workflow- VERSION() doesn't work right, so why not just put the version in Workflow.pm in the first place. Chris
Re: how to set $VERSION throughout distribution
I agree with Chris here. And the idea is not to have main package version drifting from distribution version or the other way around. jonasbn On 13/09/2009, at 15.18, Chris Dolan wrote: On Sep 13, 2009, at 7:36 AM, Shawn H Corey wrote: Jonas Brømsø Nielsen wrote: dist_name = 'Workflow', dist_version_from = 'lib/Workflow.pm', I would be tempted to: dist_version_from = 'lib/Workflow/VERSION.pm', Comments? I thought about that too and rejected it as unnecessary complexity. You still need a $VERSION in Workflow.pm anyway or else Workflow- VERSION() doesn't work right, so why not just put the version in Workflow.pm in the first place. Chris
Re: how to set $VERSION throughout distribution
Hi David, Having a uniform version number for all packages in a distribution is a good strategy. Especially in relation to back-tracking to original distribution. If a package is later lifted out it can continue it's (new)life with a new uniform version number. As long as the version numbers are sequential things should not go wrong. jonasbn On 13/09/2009, at 14.19, David Golden wrote: On Sun, Sep 13, 2009 at 7:50 AM, Jonas Brømsø Nielsen jona...@gmail.com wrote: 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', That's a great point. I wrote a short article defining what I call a well-formed distribution -- where the distribution name is the same as a module name (with appropriate :: mangling) and the distribution version is the same as the $VERSION of the package of the same name. http://www.dagolden.com/index.php/308/packages-modules-and-distributions/ Personally, I'm of the school of setting all $VERSION the same so that they clearly indicate which *distribution* they came from. While I don't use it personally (I have my own tools/workflow), the perl-reversion script in Perl-Version makes this easy. Unfortunately, it's in the examples folder, so it isn't installed by default. http://cpansearch.perl.org/src/ANDYA/Perl-Version-1.009/examples/perl-reversion -- David
Re: how to set $VERSION throughout distribution
Jonas Brømsø Nielsen wrote: I agree with Chris here. And the idea is not to have main package version drifting from distribution version or the other way around. jonasbn On 13/09/2009, at 15.18, Chris Dolan wrote: On Sep 13, 2009, at 7:36 AM, Shawn H Corey wrote: Jonas Brømsø Nielsen wrote: dist_name = 'Workflow', dist_version_from = 'lib/Workflow.pm', I would be tempted to: dist_version_from = 'lib/Workflow/VERSION.pm', Comments? I thought about that too and rejected it as unnecessary complexity. You still need a $VERSION in Workflow.pm anyway or else Workflow-VERSION() doesn't work right, so why not just put the version in Workflow.pm in the first place. Chris Because then you have to update more than one module. Shawn's Programming Rules #5 http://www.perlfoundation.org/perl5/index.cgi?shawn_h_corey#shawn_s_programming_rules: 5. If you have the same data in two places, they will get out off sync. Write the code to detect and correct this now, because when it happens, it will be too late. Try: package Workflow; use Workflow::VERSION; $Workflow::VERSION = $Workflow::VERSION::VERSION; -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy.
Re: how to set $VERSION throughout distribution
Because then you have to update more than one module. Shawn's Programming Rules #5 http://www.perlfoundation.org/perl5/index.cgi?shawn_h_corey#shawn_s_programming_rules: 5. If you have the same data in two places, they will get out off sync. Write the code to detect and correct this now, because when it happens, it will be too late. You just need something to keep them in sync. I have a script that sets all the version and double-checks them (and does so much more as well) before I make a release to CPAN. package Workflow; use Workflow::VERSION; $Workflow::VERSION = $Workflow::VERSION::VERSION; This sort of strategy caused problems with the CPANPLUS module code awhile back in that the 'cpan-r' command showed its submodules to have no version numbers. Not sure if that's all been fixed now, but it did illustrate to me that trying to set versions via a version module is not a robust scheme.
Re: how to set $VERSION throughout distribution
On Sun, Sep 13, 2009 at 10:45 AM, Jerry D. Hedden jdhed...@cpan.org wrote: package Workflow; use Workflow::VERSION; $Workflow::VERSION = $Workflow::VERSION::VERSION; This sort of strategy caused problems with the CPANPLUS module code awhile back in that the 'cpan-r' command showed its submodules to have no version numbers. Not sure if that's all been fixed now, but it did illustrate to me that trying to set versions via a version module is not a robust scheme. I suspect that to work correctly with ExtUtils::MM-parse_version (the canonical way to get a module version without actually loading the module), it would need to be like this: package Workflow; use Workflow::VERSION; $Workflow::VERSION=$Workflow::VERSION::VERSION; parse_version() does an eval() on a single line. This is why there is the idiom for version.pm: use version; our $VERSION = version-new(v1.2.3); -- David
RE: how to set $VERSION throughout distribution
-Original Message- From: David Golden [mailto:xda...@gmail.com] Sent: Sunday, September 13, 2009 4:29 PM To: Shawn H Corey Cc: Jonas Brømsø Nielsen; dhu...@hudes.org; module-authors@perl.org Subject: Re: how to set $VERSION throughout distribution On Sun, Sep 13, 2009 at 8:36 AM, Shawn H Corey shawnhco...@gmail.com wrote: Jonas Brřmsř Nielsen wrote: dist_name = 'Workflow', dist_version_from = 'lib/Workflow.pm', I would be tempted to: dist_version_from = 'lib/Workflow/VERSION.pm', dist_version_from is also used as a default for where to find author informaiton and such. Best is probably just module_name = Workflow $David++ That sets dist_name to Workflow and dist_version_from to lib/Workflow.pm -- David
RE: how to set $VERSION throughout distribution
-Original Message- From: David Golden [mailto:xda...@gmail.com] Sent: Sunday, September 13, 2009 3:19 PM To: Jonas Brømsø Nielsen Cc: dhu...@hudes.org; module-authors@perl.org Subject: Re: how to set $VERSION throughout distribution On Sun, Sep 13, 2009 at 7:50 AM, Jonas Brømsø Nielsen jona...@gmail.com wrote: 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', That's a great point. I wrote a short article defining what I call a well-formed distribution -- where the distribution name is the same as a module name (with appropriate :: mangling) and the distribution version is the same as the $VERSION of the package of the same name. http://www.dagolden.com/index.php/308/packages-modules-and- distributions/ Personally, I'm of the school of setting all $VERSION the same so that they clearly indicate which *distribution* they came from. While I don't use it personally (I have my own tools/workflow), the perl-reversion script in Perl-Version makes this easy. Unfortunately, it's in the examples folder, so it isn't installed by default. I too have a hand crafted code to change the versions. It's not such a parser and will be broken under other people's code probably, but works under my code :) Here is what I do to build distros: I have a builder builder program that first asks me which module to build and then copies the main distro files into a temp dir and injects a M::B subclass into that directory then starts to build the distro and the subclass then updates versions, do some other stuff etc. Keeping the builder seperate (repo) from the actual module code seems like a more clean path to me. http://cpansearch.perl.org/src/ANDYA/Perl-Version-1.009/examples/perl- reversion -- David
RE: how to set $VERSION throughout distribution
-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
Re: how to set $VERSION throughout distribution
Burak Gürsoy wrote: Indeed. I also don't like $VERSION = localtime() stuff like $VERSION = 20090913.foo thingies. Just nonsense. I use the three number form: $VERSION = q(v1.2.3); '1' is the major version number; it only changes when the API changes. '2' is the minor version number; it changes when the API is augmented. '3' is the revision number; it changes with every bug fix and security update. I don't use the pragmatic `version` since it is not install with Perl yet. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy.
Re: how to set $VERSION throughout distribution
I use the three number form: $VERSION = q(v1.2.3); This may cause problems because it makes $VERSION a string, namely, v1.2.3. This prohibits numeric version comparisons which is the norm. It also means your CPAN modules will get called something like Mod-Name-v1.2.3.tar.gz which is also non-standard.
Re: how to set $VERSION throughout distribution
On Sun, Sep 13, 2009 at 4:25 PM, Jerry D. Hedden jdhed...@cpan.org wrote: I use the three number form: $VERSION = q(v1.2.3); This may cause problems because it makes $VERSION a string, namely, v1.2.3. This prohibits numeric version comparisons which is the norm. The quoting definitely will cause some issues. v-strings by themselves ($VERSION = v1.2.3) generally will work OK, *except*: * Parts of the toolchain (e.g. ExtUtils::MakeMaker) can't deal with v-strings in PREREQ_PM. * Foo-VERSION will return different things depending on the version of perl and whether version.pm was loaded (by *any* module anywhere in the process). * Never use alpha v-strings, e.g. v1.2_4. How that behaves is radically different on older versions of perl. * If users say use Foo 1.002003 because they are used to specifying use 5.006002 for perl 5.6.2, this could fail on perl's compiled for long doubles with the bizarre error: Foo version 1.002003 required--this is only version 1.002003 It also means your CPAN modules will get called something like Mod-Name-v1.2.3.tar.gz which is also non-standard. It's no longer non-standard, at least as far as PAUSE and the toolchain are concerned. In fact, it's likely to become standard, following the convention that all dotted-integer versions should be expressed in normal form with the leading v. I still recommend decimal $VERSION numbers, with eval afterwards to clean up alpha version. Gory $VERSION details here: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ -- David
