Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re: Per-distro versioning and dependency specification

by tobyink (Canon)
on Jun 06, 2012 at 09:04 UTC ( #974677=note: print w/replies, xml ) Need Help??

in reply to 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;

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

When 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'

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();

    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();

    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?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://974677]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2020-10-29 13:24 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (271 votes). Check out past polls.