http://qs321.pair.com?node_id=359254


in reply to Re: Re: Re: The quantity vs. quality lesson
in thread The quantity vs. quality lesson

Actually diff could use some shape up as for intra line and binary diff...

But if a Module - lets say my favourite Parse::RecDescent will have it's last update in 2001 and we'll have the year 2007, then I see no problem:

And I'm not saying newest is best. I thought I could discuss at the monastery, on some sophisticated level where it is not necessary to say everything explicitedly.

Bye
 PetaMem
    All Perl:   MT, NLP, NLU

  • Comment on Re: Re: Re: Re: The quantity vs. quality lesson

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: The quantity vs. quality lesson
by eserte (Deacon) on Jun 02, 2004 at 09:56 UTC
    Modules should never be removed. Other scripts and applications may depend on them, and I consider backward compatibility to be an important feature.

    Rather write a comment on cpanratings if you think that a module is bad, or add a bug report on rt.cpan.org. Share your knowledge with the community, it is already possible. Right now.

      Is it really the case that scripts and applications that depend on old modules will get broken if they are removed from CPAN?

      I know when I use modules on CPAN I make local copies, and don't run them from the 'net. I'm not sure it's feasible to do otherwise.

        Well, there's backpan, which holds everything ever uploaded to CPAN. But if a module is not anymore at CPAN, then it is more difficult to find it through search.cpan.org or impossible to install with CPAN.pm.
        Is it really the case that scripts and applications that depend on old modules will get broken if they are removed from CPAN?

        They would be broken in the sense that if module Foo depending on CPAN module Bar, and module Bar was removed, then Foo could no longer be easily installed via CPAN. The person who wanted to use Foo would have to figure out what had happened and install Bar manually from backpan.