Re: Re: Re: Re: The quantity vs. quality lesson

[PetaMem]

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:

• Keeping it if there will be no other module (and we know Damian won't write it) like Parse::FastDescent with same API, but just functionally equivalent/better and faster.
• Moving it to CPAN-Nimbus else

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.

[eserte]

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.

[BlaisePascal]

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.

[eserte]

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.

[adrianh]

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.