Re: Per-distro versioning and dependency specification

I always keep the version numbers of modules in my distributions synchronised. While using different version numbers in different modules can be handled sanely, it seems to me there is at least potential for confusion. On the other hand, synchronisation doesn't appear to have many drawbacks. If I bump the version number of one module, then it doesn't seem harmful to bump the version numbers of the rest, even if they haven't seen any other changes.

With regard to changing major version numbers when breaking backwards compatibility, personally I don't think that goes far enough. If I write:

use Foo::Bar 2.00;
[download]

... but Foo::Bar 3.00 has a completely changed API, then my code may break in unexpected and confusing ways.

When JSON.pm changed its API between versions 1 and 2, this caused a lot of breakage. The only way to avoid that is to continue to support your old API alongside the new one. In practice this usually means giving your new API a different module name (and perhaps rewriting the old module as a wrapper for the new one).

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Comment on Re: Per-distro versioning and dependency specification Download Code

Replies are listed 'Best First'.

Re^2: Per-distro versioning and dependency specification
by creamygoodness (Curate) on Jun 06, 2012 at 11:08 UTC

It's tough to handle backwards compatibility breaks sanely in a dynamic environment. I agree that if you want to avoid disruption entirely in Perl 5, package renaming is the only option, and have in fact done something like what you recommend in the past.

Things would be easier if the language offered namespace aliasing a la Python and the community had a tradition of Java-like package namespaces.

use org::apache::spamassassin3::Mail::SpamAssassin as SpamAssassin;
my $spamtest = SpamAssassin->new();
[download]

Using the aliased module, you can almost get there in Perl 5, though aliased only aliases one package at a time rather than the whole hierarchy.

# Works:

use aliased 'org::apache::spamassassin3::Mail::SpamAssassin';
my $spamtest = SpamAssassin->new();

# Doesn't work:

use aliased org::apache::spamassassin3 => 'SA';
my $spamtest = SA::Mail::SpamAssassin->new();
[download]

Can you imagine the abuse that would rain down on someone who uploaded a tarball like org::apache::spamassassin3-3.31.tar.gz to CPAN, though?

[reply]
[d/l]
[select]


We don't bite newbies here... much
	PerlMonks