I'm writing an interface to a lexicon in Java. I just started this project, and the lexicon is on version 3.8. When a new version comes out, say version 4.0, database columns may be renamed, removed, added, re-organized, etc. The database could be totally different, and my 3.8 interface would not work with it, so I would need to update the library to interface with 4.0. However, I also want to maintain backwards compatibility with 3.8, and continue to do development on all versions until I drop support for them.

I believe that source code control software like Git (which I'm using for the project) can make maintenance and feature addition to different versions really easy through branches and release tags, but I'm not sure how to organize the project.

How does one manage a single library that interfaces with multiple versions of a data source, that may each need continued development?

My thoughts:

  • Most recent version of the library's development goes in master
  • development for old versions are in OLD_VERSION_XXXX branches where XXXX might be:
    • stable
    • development
    • any random feature/bugfix branch that gets merged into dev or stable for that version
  • Use Releases and Tags in Github to ensure consistency between these versions, and to release new compiled versions when necessary

Note: This is a personal project that (probably) only I will use, but I want to apply some real-world practices the right way.

  • If you are alone, focus only on the two last versions. Commented Sep 4, 2015 at 17:42

1 Answer 1


Two things come to mind.

  1. Encapsulate the thing that changes into its own class and/or interface, and provide a factory to get the desired version. This works well if the "data access" is the only thing that changes.

  2. Create an adapter layer that acts as the compatibility layer between version X and version Y. You might have a bunch of classes in this layer but it could blunt the impact of non compatible API changes at the expense of some performance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.