Research on how module authors "negotiate" breaking changes in software package managers

I am a subscriber to and thought I’d repost something written there for the wider community.

Chris Bogart, a postdoc at Carnegie Mellon, is interested in studying how different language-level package managers and repositories handle breaking changes. He has observed that different package management systems have made “very different design choices from each other,” and he would “like to know what the impact of [CPAN’s] design choices are on how you negotiate breaking changes among CPAN module developers when the packages depend on each other.”

If you have released modules on CPAN, and especially if you have thought about making breaking changes to your module, or have made breaking changes to your module, I’m sure you’re ideas would be helpful. If you have had to deal with an upstream author’s breaking changes, I’m sure that would be helpful, too.

1 Comment

FWIW, when I did Catalyst deployments I tried hard to avoid breaking stuff, but if I needed it I tried to provide some remediation such as configuration flags that could be set to provide backward compatibility (like with the UTF8 changes) or some external new module that returned old features (such as we did the the regex dispatcher).

In general when I do modules I try to maintain compatibility. Unless I explicitly say in the introduction to the module that I am still experimenting (like with Template::Pure) I consider my API to be a type of contract with my users.

Leave a comment

About David Mertens

user-pic This is my blog about numerical computing with Perl.