Re^2: Is maintaining multiple versions of a CPAN module a terrible idea?

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

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

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

Replies are listed 'Best First'.
Re^3: Is maintaining multiple versions of a CPAN module a terrible idea? by hippo (Bishop) on Jun 06, 2014 at 15:46 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^3: Is maintaining multiple versions of a CPAN module a terrible idea?
by hippo (Bishop) on Jun 06, 2014 at 15:46 UTC

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.

[reply]

In Section Seekers of Perl Wisdom