Obviously it depends on what the application is but in general :

• Choose modules that are highly rated on cpan ( http://search.cpan.org/~mjd/Memoize-1.01/ )
• Choose ones that have been recently updated, or are in higher versions, as they generally are better maintained and more developed ( http://search.cpan.org/~gfuji/Data-Util-0.53/ )
• If you can use modules which have been assimilated into the core release, this is often good too, because they are stable and well tested ( File::Basename )
• Look around - are people here using them ( Super search )? What do they say?
  (If you have a more specific request, and a particular module doesn't rock your world, tell us why, ask us of there is a solution, maybe someone will know a better module...)
• Mainly though, play around!
  • find what suits your style
  • what gets the job done ( Test )?
  • What gets it done fastest ( Benchmark ) ?

Choose ones that have been recently updated, or are in higher versions, as they generally are better maintained and more developed

That's quite a bold statement. Lots of activity may also be a sign of a high bug rate, or creature feep. "High" versions numbers are an even less useful indication. Is PHP an on par choice to Perl because both have (major) version number 5? Will PHP become a better choice if they declare their 6.0 to be ready before Perl does?

If you can use modules which have been assimilated into the core release, this is often good too, because they are stable and well tested

So you hope. That's only true for part of the modules in the core. Many "core" modules are "dual released" - the modules are found on CPAN, maintained (or not...) by someone other than p5p, and are just synced with the latest CPAN version before a Perl release. Inclusion in the core doesn't mean more than that someone in the past thought it was a good idea. And once there, it'll be there forever. Witness modules like CGI and Text::Soundex.

Once there, it'll be there forever.

That may change in Perl 5.11.x; Switch is on the way out, for example.

As others have said, the version numbers or age of last release can be misleading. I'd suggest you look at the RT via search.cpan.com and see whether there are long unattended bug reports (bad) and whether there are any closed bug reports. If there are no, either it had always been so good that there was no need or no one uses the module. Hard to say which.

I would also place the "Look around" quite a bit higher in the list. The ratings are not used enough to actually be a good indicator of module quality.

Jenda
Enoch was right!
Enjoy the last years of Rome.

• Read the documentation for each candidate module using perldoc or by browsing CPAN.
• Decide which have the minimum capabilities you need
• Select the one which fits your needs and which you find easiest to grok

There is no rating service that I know of, but there are lots of deciding factors you can use:

Is it still maintained? Good indicator is if there was a new version in the last year (don't depend on it, some old modules are so "finished" that there is no need for a new version)

Is there talk about it? Search perlmonks if it is mentioned in any threads. Often the thread tells you of alternatives and which is the best mod to use in most cases

Which one has the features and interface you want? Often modules are all of high quality, just for slighty different needs or tastes

If that still doesn't decide it, look at the source package. Does it use warnings and strict? Has it lots of tests? The number of tests and whether they fail on lots of platforms can also be looked up at http://static.cpantesters.org/

There is no rating service that I know of

CPAN Ratings?

I would submit that all we monks can do is point out the pitfalls &/or benefits of using particular modules in order to allow you to arrive at a/the decision for yourself - that being said, ultimately the decision should be based on whichever module you feel most comfortable with from the POV of usage, feature(s)/functionality & documentation.

I am relatively new to modules myself so what I do is I identify my situational requirements, zero-in two or more modules potentially capable of doing the same and I ask the more experienced monks about the pros and cons for each one of these modules then make an informed decision on which one to pick for the job at hand. Crucial to tell you "Make sure you've an overview of the modules you intend to ask about - as stated by replies to your post - and that you understand what you are asking in case you needed a consultation on the best track to follow".

Excellent advice, I would like to just add/clarify one point.

... and one that has an active mailing list ...

Not all active modules have mailing lists, many module communities are more active on IRC and less so on the mailing list (Moose is a perfect example of this, the mailing list is pretty low traffic but we have 200+ people in the IRC channel at any given time).

And of course there are several active authors who don't like mailing lists or IRC and prefer that people just contact them directly.

-stvn

I adore you, stvn, and this isn't directed at Moose in particular. Just a good example and timing. I want to go on the record (probably should have saved this for a meditation) with this idea: IRC Considered Harmful.

IRCs are knowledge holes even when they are archived and searchable which many (most?) are not. The signal to noise ratio is too high to make them fun or effective to search even when you can; bad answers mixed with good; hacks mixed with best practice; sigils and stopwords galore. Too much intrinsic context; not stateful.

Excellent or important answers and clarifications happen in them all the time without being recorded or refined into a form which would be valuable to more than the two or three users paying attention. IRCs are anti-DRY.

IRCs also nurture clique behavior which can be discouraging to outsiders and would-be contributors even when genial and when it's not friendly it's easy to get away with being a jerk in a chat; it's familiar to the regulars and ephemeral. It's very difficult to get away with it on a mailing list; you often get dogpiled when you try.

I know I'd love to hang around with you personally. I am sad for all the things about MOP or Kioku or DBIC or ... which have zipped through the IRCs without landing in the right™ and "permanent" places: the documentation and tutorials (personal, community, or distributed with the code).

(Sidebar: I will buy you drinks if you're ever in my town. Then we can plumb some real knowledge holes.)