If you want to put a version on CPAN but don't want the general CPAN shell users to try to installing it, put a `_' in the version number (e.g. 0.40_01) in the tarball name. CPAN.pm will ignore that version unless it's explicitly requested (install F/FO/FOO/MyModule-0.40_01.tar.gz). Check perldoc CPAN for (slightly) more detail.

If you are going to do it, then the new version at the least should be a new major version, and probably should get a different name. Otherwise if at all possible, I would provide a backwards compatibility interface.

Yeah, it sucks. But the advantage of modularity is that you will provide an interface that others can rely on to not change as you change the guts. The deal is that they don't mess with your internals, and you won't break their code. Both ends of that deal are important, and I try to avoid relying on code from people who knowingly break documented APIs in released code.

I agree that changing the interface is *bad*. When writing, I would try to avoid it if at all possible, and if necessary, rename functions to fix this; another advantage of perl's weak typing is that it's probably very easy to 'overload' a function to take arguments in a different order if that is changed, but again, I would (and will) try to avoid that. That said, there's other options to consider.

That said, another thing that I've been doing, and a lot of others on CPAN apparently, is keeping the version number of what I would consider to be "use at your own risk" code at 0.xx. Once the code hits 1.xx, or any higher number, there's an implicit understanding that the code is well tested, and any additional updates are bug fixes and feature improvements, over mechanistic and behavior changes (until, of course, the next major number change). Certainly this is informal, but it seems to be consistent for module developers. Can this be a reasonable guarntee, particularly for newer (< 3 month old) modules that might yet have a large in-use distribution?

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Perhaps distributing the Beta as a separate package would be better? That way it wouldn't be somewhat hidden. Anyone browsing CPAN directly would see it separately, and perhaps you could wire a message into the make sequence to notify people of the Beta. Thus, someone using CPAN.pm would also be made aware of it.

HTH

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

I prefer Masem's approach, if only because it's simpler (just one package to worry about). The only issues I can see with it are:

• Reduced visibility of the beta code (which isn't necessarily an issue: you don't really want people finding beta code before a stable version that already does what they want, and when they grab the stable version, oh hey, here's a beta module to try out)
• increased footprint (extra code means extra files that the user doesn't have much of a choice about downloading, which might be annoying for student users with fascist disk quotas to worry about).
--
:wq

This really depends on how many people are using your code. If you were making changes to LWP, you would have a much different strategy than if you were making changes to a module only a handful of people actively use. If only a few people use it, then just warn the folks using the module, make the change and be done with it. Otherwise six months from now someone using an older version of your module will have a problem and you won't be able to remember when you made a particular change permanent, etc. Who needs that?

Also, I think it's confusing to distribute in the same module beta code that duplicates functionality of stable code. Most people will never use it (they just need to get a job done), so you've gone and confused them without any benefit (comments, patches, etc.) to yourself. The people who will actively use beta code are likely motivated enough to download a separate package from a separate site.

All IMO, of course :-)

Chris
M-x auto-bs-mode

I think a name like My::Module::Beta is a really bad idea. It pollutes the namespace with junk. Better ideas:

1. If it's such a radical redesign of the interface, consider using a different name altogether that better reflects what the module does;
2. Increase the version number, and note that it's beta by putting an underscore in the version (ie, 2.00_01). Also note very prominently in the README and POD that the interface is redesigned
3. Use different function or method names, and have the old function names call the new functions. In your docs note that the old interface is deprecated, and in a far future version remove them