iphone: Good practice for keeping my third-party libraries up-to-date?

Question

Hi all, I want to ask about your practices to keep your third-party libraries up-to-date easily.

In my iPhone project, I use quite a lot third-party libs (like TouchXML, JSON, RegexKit, YAJL, MGTwitterEngine...). Most of them is stored in GitHub and their version, especially MGTwitterEngine, change quite rapidly (because of adding new feature, fixing bug, changing in Server(like Twitter) response format...).

Sometimes, I forget to update (also don't want to change the stable version) then my project get bugs because of out-of-date libraries.

When I got a bug because the old libraries. I often go to Github, download the new version, then need to change a lot of code. Because downloading new version means I do a fast-forward from a very old version to the latest version. I think It will less painful if I update the library more frequently.

What is your approach for this task?

Answer 1

Have you looked into git submodules?

I use them for this task. We have a repository of helper classes. However, whenever we make additions & improvements, we want those improvements to be cascaded to all of our projects -- so, we set up that helper repository as a submodule in each project repository.

Try the following command from within your repository's root directory:

git submodule add ssh://url/to/external/library.git local/path

This should do the following steps (taken verbatim from the URL above):

• Clones the submodule under the current directory and by default checks out the master branch.
• Adds the submodule's clone path to the .gitmodules file and adds this file to the index, ready to be committed.
• Adds the submodule's current commit ID to the index, ready to be committed.

You can then use the

git submodule update

command to keep things up-to-date.

Also, as a side note, if you are doing what I am (e.g. making direct changes to the submodule repository), you need to go to the submodule's root repository directory and commit those changes FIRST before committing the super-project. This is because git keeps track of the versions of the submodules (smart), so if you commit the superproject first, you'll be storing a reference to changes that haven't been committed on the submodule repository. Anyone who tries to clone your superproject will get an error.