Wednesday, August 4, 2010

Forking Codebases

So Cerego is going to discontinue official support of their version 1 SmartFM API as of August 31st, which is a shame, as I use that API in my SmartFM Mobile Study Dictionary app (available in the Android marketplace).

I'm going to be switching over to the unofficial version 2 SmartFM which is JSON rather than XML based, so I'm trying to rework the app before the August 31st deadline. I managed to get some preliminary JSON communications going, and since the android test harness is too damn slow I created a separate standalone non-android Java SmartFM JSON client library. So now I'm just about ready to blast through all the old XML communications and change to JSON, but first I wanted to check that this separate library was actually going to work as an android plugin, particularly since I had pulled in a different JSON library to get the standalone test framework to work.

So I created a brand new Android Shell to check that the linkage worked, and it was good, but I started wondering if I shouldn't be forking my existing codebase since I want to be able to apply small fixes to that, and perhaps pull them directly into the new codebase. Also, I need to work quickly to get this all done by the August 31st deadline, so I likely don't have time for the complete rewrite I would like ("release early, release often"), however maintaining a long term fork seems rather involved. I found a walk through of how to do that:

On balance it seems more trouble that its worth, so I'm going to work with a new repository and move things over piecemeal. Still I'll try and move code over without trying to fix too much, as experience tells me that trying to fix too many issues at once is asking for trouble. The main issues I want to address are removing global variables and unsightly spaghetti code, making the voice recognition auto search, and streamline the content creation process. Better get that JSON stuff working first though :-)

No comments: