http://www.perlmonks.org?node_id=1088910


in reply to Is maintaining multiple versions of a CPAN module a terrible idea?

Unless the mechanisms governing PAUSE uploads and indexing have changed, it’s impossible to release an earlier version number than what is there already. So, if you had say v3.0.1 for a legacy version and want to release a bugfix v3.0.2 you cannot (formally/CPANally) do so if you have released new version v4.

A name change or a number in the name skirts the issue. It’s not unheard of even though it’s a little clunky; e.g., LegacyXyz and LegacyXyx2.

Two versions sounds nice/kind and I appreciate your willingness to keep them up if you can work out how.

  • Comment on Re: Is maintaining multiple versions of a CPAN module a terrible idea?

Replies are listed 'Best First'.
Re^2: Is maintaining multiple versions of a CPAN module a terrible idea?
by tobyink (Canon) on Jun 05, 2014 at 21:54 UTC

    If you've released 4.0, then you can upload 3.0.2, but it won't be indexed. This doesn't stop people from manually downloading 3.0.2 and installing it though.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

      Thanks to both of you for these clarifications. It sounds like this will be the only significant hurdle and that it can be overcome (or at least dodged) by out of band means. One step is to maintain a page elsewhere with clear and easy access to the lastest legacy version. In tandem with this, the docs for the newer version should point to that page and ideally the installation process should check the running version of perl and error out if it is too old with a suitable message to point to the legacy version.

      For now, this seems like the best approach. It should give the legacy users enough pointers to their newest version and allow me to develop and release both branches independently.

      Thanks everyone for your very useful comments.