Re: Minor API changes in 10-year-old module

in reply to Minor API changes in 10-year-old module

Well, one option is to release it as an entirely new module. The advantage of this is the people looking to upgrade can do so, and everyone else can putter along with their stable legacy code. You could put a reference in the original module's documentation about the new module and explain the improvements.

Otherwise, you probably just want to make sure it's as backward compatible as possible. If it's not that popular, it's less of a risk introducing changes.

Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Comment on Re: Minor API changes in 10-year-old module

Replies are listed 'Best First'.
Re^2: Minor API changes in 10-year-old module by wanna_code_perl (Friar) on Sep 05, 2019 at 19:13 UTC
Thanks for the suggestion. Unfortunately, it's already in the ideal CPAN namespace for what it does, and from a functional standpoint, my version adds a couple of features (strict superset, new features don't affect backwards compatibility), and fixes a few bugs. I broke backward compatibility intentionally, since it was pretty much impossible to use the module's existing API without some kind of undefined behavior.	[reply]

Replies are listed 'Best First'.

Re^2: Minor API changes in 10-year-old module
by wanna_code_perl (Friar) on Sep 05, 2019 at 19:13 UTC

Thanks for the suggestion. Unfortunately, it's already in the ideal CPAN namespace for what it does, and from a functional standpoint, my version adds a couple of features (strict superset, new features don't affect backwards compatibility), and fixes a few bugs. I broke backward compatibility intentionally, since it was pretty much impossible to use the module's existing API without some kind of undefined behavior.

[reply]

In Section Seekers of Perl Wisdom