If the distribution has been around a while, I'd rename it under the new namespace, and make prominent notices in the original dists POD that you won't be updating this one any further, link to the new one and state to use that, and the existing one will stay in place as to not break applications that are currently using it. (However, if you happen to realize there are severe security or data loss type issues, backporting would be a pretty reasonable/decent (update proper /update) thing to do if you know people are using the deprecated version).

Hello gnosti,

Here’s an article by Neil Bowers which, essentially, reinforces the points made by stevieb, above:

Don't be afraid to rename your module / dist

Hope that helps,

I would do the following:

• Create a new distribution under App::
• Create an interface under the old Module name to provide interface compatibility.
• Release in lockstep
• Correct any migration bugs until stable
• Deprecate the old module and release
• profit

"Deprecate the old module and release"

Agreed, but as I've learned through experience, one can't dump a "shit... I made a mistake", I'll rename this when even one user is using your distribution. It sucks, and it's a learning curve... my advice is ask here on Perlmonks (or any other site that is legit for CPAN naming) then do due diligence. It's a hairy situation, because there's no one confirmation that can be made.

If you've already published a distribution, don't dump it if you even smell a single person is using it. Burn another namespace, but ask first. Again modules <at> cpan.org.

Perhaps an alternative to this could be to migrate the interface module (previously the old module) from its own distribution into the new package. Being unable to depreciate a module, ever, gave us MS DOS ;-).

--MidLifeXis

On reflection, a name change will not make a niche or "me, too" application become mainstream, but could be meaningful.

I note that some larger applications and frameworks have a single name (Padre, Kephra, Moose, Mojolicious, Statocles, Dancer.) There is some criticism of this "branded" approach

I am one such critic. If you saw one of those modules used in someone's code and were not already familiar with it, could you tell from the name what its purpose was? Me neither. Why is Moose not named OO::Moose? At least then the casual observer would have an idea.

If you name the dist in some manner that explains simply what it does then that clarity helps everybody.

Feel free to disagree :-)

As a CPAN author over a few years, I concur with the sentiments here.

Top-level namespaces should be used sparingly. If there is a good reason to use one, it is what it is, and should provide the ability/availability to allow a whole host of sub namespaces.

Naming something at the top-level because you think it'll "sell" is not appropriate (although it goes through unchecked). When in doubt, send your desired namespace to modules <at> cpan.org, and see what they think of it. If you're going under something else, such as App::, do your own due diligence, ensure it doesn't collide, ensure it makes sense, ask here for reflection, then do it.

Always, doing due diligence in your path selection is desired, and you're respected here for doing just that.