To shoot yourself in the foot: maintain multiple branches

One of the rules with hosted projects is to not introduce radical API changes (or depending on your understanding even new features) in point releases of stable branches of contributed modules, so you are supposed to open a new branch. The hell starts to break loose however, if you don't have an eye on what is actually happening in your branches. This happened to me and it affected the Drupal 6 translation efforts so it was just the right time yesterday to finally clean it up. Here's the story.

Potx module (or translation template extractor) is a nice little tool which is the successor to extracor.php (for those, who have been long in the community), but is packaged as a module, so it allows a lot more. It has a web interface to extract translation template files for modules in Drupal 5. It is also an "API module", plugging into Localization server, parsing modules and themes and Drupal itself there.

So with Drupal 6 coming along, I ported this module to Drupal 6 as well a few months ago. And then ventured on to implement a "new features" branch as 6.x-2.x which also allows to generate templates for themes on the web interface (not jut in the API), and offers coder module integration, which allows you to include translatability error reports in your code reviews as well. I also took the opportunity to clean up some APIs. That's all cool.

What's not cool, is that the 5.x version got some fixes due to its usage in Localization server, the 6.x-1.x version got fixes due to it being used as a template generator for Drupal 6 translation template packages in CVS and the 6.x-2.x version got fixes due to me going through the code and singling out stuff not required anymore (remains from Drupal 4.6 days). To top this off, I also had an 5.x-2.x branch where I intended to backport the API changes from 6.x-2.x but never got around to it, so it was basically still a copy of 5.x-1.x. So all the code was too different, and I felt more and more uncomfortable on what patch to commit to what branch, in fact I had no idea on the differences between the branches (the above is just a reconstruction I made after sitting down and finding everything out again).

So since some translators were pressing hard to have the Drupal 6 targeted fixes available in the Drupal 5 version, I needed to sit down and do diffs between each branch of the module, which resulted in porting fixes from the 5.x version to 6.x, back from the 6.x-2.x version to all earlier versions and finally back from 6.x-1.x to 5.x-1.x and 5.x-2.x. Through the process, I also draw a nice graph of what is different between the branches, so I know exactly where to look for something.

Now I feel much more comfortable, maintaining multiple branches will be much easier, but ultimately the goal is to not maintain multiple branches, so what I done additionally is that I released the 6.x-2.0 version with the new features and API changes, and set that to be the default for the 6.x series. I put aside the 5.x-2.x version for now, since it is basically the same as 5.x-1.x for now (it might be even better to revoke it after all). So I have a clean picture of maintaining the 5.x-1.x and the 6.x-2.x branches, and know the exact differences between them for confidence.

I can only suggest the above to any project maintainer. Know your code, your branches, so you can work quicker and smarter. A bit of a mystery around your own code just stops you from working with confidence.

Add new comment