develooper Front page | perl.perl5.porters | Postings from August 2014

Re: Criteria for becoming/dropping a core module [was: Re: maintainerwanted: Time::Piece]

Thread Previous | Thread Next
Kent Fredric
August 1, 2014 01:38
Re: Criteria for becoming/dropping a core module [was: Re: maintainerwanted: Time::Piece]
Message ID:
On 31 July 2014 23:51, Neil Bowers <> wrote:

>   5. Modules for talking to your environment (Cwd, File::Spec*)
> (?)  6. Developer / introspection (B::, Module::CoreList)
>   7. Codifies best practice / language extensions (autodie)
>   8. "Batteries included"

5, 7 and 8 could easily be regarded as ideal candidates for a "Standard
Library" that could still exist, but be shipped independently of Perl
itself. Some, but not all of 6 could similarly be "Standard Library".

There's long been /suggestions/ that doing something like this "would be
nice", but nobody has yet managed to.

Essentially we already have such a standard library, just its invisible,
unnamed, and its version is always the same as perl itselfs.

Having them integrated as a non-release coupled standard library would mean
you could decouple the release cycles of the standard library from perl, so
having things *in* a standard library would not be possible to slow down
the release cycle of Perl itself.

Then one day down the road we can shift some of the discussion from "Do you
have Perl 5.20 installed" to "Do you have at least Perl 5.20 and standard
library 6.50".

And it seems it would be much easier to get a service provider to upgrade
the standard library ( given it would be tested and known to work on both
future and existing perls ) in places they'd be less inclined to upgrade
perl itself, and in places they're less inclined to install arbitrary CPAN



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About