Blogging Pubbitch

You've maintained a temporary fork of a library for a while, but you need to ship your product to external customers, or the developers of the library aren't interested in your fixes, or you're just feel that what you'd like to do most with your precious free time is to maintain a library.

The only decent thing to do is make the fork permanent.

There's a whole bunch of choices to make here, but they all start with the same action: changing the package name. Unless you're officially taking a project over, this single action means that other teams can make a reasoned choice about migrating from the original version to yours. It also means that as your fork and the original diverge teams don't have to fight about which library they should be using.

If you're forking so that you can ship a product or project, then changing the package name decouples your project from the forked library's release schedule: you become free to ship with snapshots with your fixes applied. If you're forking because the underlying library has some major issue that's not being properly addressed, you put yourself in a great position to open that project up to other contributors and allow yourself the freedom to change APIs as you see fit. Lovely.

Actually, the case where you're forking to allow your product to be released is an interesting one. It's similar to the case where you want a temporary fork, in that you probably want to continue tracking the current HEAD release so that you can fall back to the original library as soon as possible. In this case, the best thing to do is to automate the package renaming; write a script that does the grunt work of renaming the packages. You can then hook it into the process described in my previous post, meaning that you have the advantages of your own private world with the opportunity to fall back to the original library when necessary.

Which is nice.