Is maintaining multiple versions of a CPAN module a terrible idea?

[hippo]

Esteemed fellow monks, I have recently taken maintainership of a very old and long-neglected module on CPAN (no names, no pack-drill). Having put out a bug-fix release and pretty much cleared that queue my attention is now turning to the future. Initially, the plan was to overhaul some of the code to bring it in line with more modern best practices (and by "modern" here I mean post-millennial) such as using strict, removing default exports and so on.

However, the code as it stands has require 5.002; and the purist in me is loathe to break backward compatibility even for such good reasons and to such an old, old version of Perl.

So, the next idea is to tidy up the existing code somewhat while still maintaining the backwards compatibility and release a "final" version under the current major number and call that feature-complete for older perl versions. Then after that work can start on the updates which would break backwards compatibility, but would be released on the next major number. I would need to keep both tracks under development, but the older one just for bug fixes, etc.

The question is: how dumb an idea is this? Am I just making problems for myself further down the line? Should I just commit fully to going one way or the other?

For the record, I do not plan on making any great changes to the API and almost no changes to the underlying functionality, so I don't think releasing the fresher version under a different module name makes much sense in this particular case.

All opinions on this matter (particularly from seasoned PAUSE users) are welcome.

[GrandFather]

The old/new major version sounds entirely sane to me. Version 1.x is available and is the approved version for old versions of Perl. It will get minimal love going forward. Version 2.x is the shiny new version tested against current versions of Perl back to say 5.10 (because that's when a lot of interesting stuff changed and there are probably still OSs around in maintenance mode with 5.10 as their system Perl).

It is a well understood and common practise that a major version bump may break stuff. It sounds like the changes you propose hardly warrant a mojor version bump because, apart from the exports change, they are pretty much internal. However the major version bump sends a pretty clear message that changes are afoot so watch out.

[Your Mother]

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.

[tobyink]

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.

[hippo]

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.

[tobyink]

I have been thinking about such things myself for post-1.000000 Type::Tiny. My planned approach is this:

• Once 1.000000 is released, further 1.000xxx versions will be bugfixes with no new features.

• While the 1.000xxx are being maintained as the main stable branch, I'll also be releasing 1.001_xxx versions with new features.

  Because of the underscore in the 1.001_xxx version numbers, PAUSE won't index them. They are developer releases only.

• Once 1.001_xxx has become stable, it will be released as 1.002000.

  Once 1.002000 is released, further 1.002xxx versions will be bugfixes with no new features.

  The 1.000xxx versions will still be on CPAN if anybody needs them. If any major bugs (e.g. security issues) come to light should be possible to upload a new 1.000xxx release, but it won't be indexed because there's already a newer version on CPAN.

• While the 1.002xxx are being maintained as the main stable branch, I'll also be releasing 1.003_xxx versions with new features.

• ... etc...

A wiki page can exist, with links to download tarballs of the latest releases in the 1.000xxx, 1.002xxx, etc branches.

[Arunbear]

What's the ETA of Type::Tiny 1.000000 ?

[tobyink]

Good question. "When it's ready." Hopefully this year.

I don't envisage any major API changes before 1.000000. I mostly just want to improve the test suite coverage. I haven't had as much time to work on that as I might have liked, but generally speaking I've found that time spent doing this has been worthwhile in terms of finding obscure (but potentially important) bugs.

[DrHyde]

Others have pointed out some stuff about how the indexer works. If the existing module is Foo::Bar and you want both that and the new one to be indexed you'd probably want to release the incompatible modernist version as something like Foo::Bar2. See Dancer and Dancer2.

Until a few years ago I would have agreed with you that maintaining backward compatibility was important - although I wouldn't go so far as to support 5.002, I used to strive to support 5.6.2. But these days I don't bother. That's what CP5.6.2AN and its many friends and relations are for.