Managing Customizations with Upgrades

Since opentaps is open source, you can make any modifications you need to make it work for you or your client's business needs. It is important, however, to make sure that your customizations or modifications can still be preserved for future upgrades. This guide discusses some best practices for managing those customizations for future releases and upgrades.

If you are customizing opentaps, we recommend that you follow these best practices:

1. Learn the existing framework and applications so you can minimize the amount of customizations which you have to do. The biggest mistake new users and developers make is writing too much code and trying to make large modifications when a small one would serve the same purpose.
2. If you are making changes to the existing code base, consider contributing it back so that it would be included in future releases. That is usually much simpler than maintaining a separate version, and other users and developers could help improve or extend your new features.
3. If you are building a new application, such as a custom online store, create it as a separate application component and maintain it with your own Subversion or CVS repository. Your Subversion or CVS repository should allow you to tag or separate your code into releases. When you upgrade to a new version or release of opentaps, just put the new component into its applications/ or hot-deploy/ directory, and it should load. As each version and release is different, please check that all your features still work.
4. If you have modifications to the core code base which you do not wish to contribute back or which were not accepted back into opentaps, then you should create your own Subversion or CVS repository to manage your own code base. Import your initial code and treat releases of opentaps as "vendor imports" to be merged against. In your code, clearly mark up changes that you have made which are not in the opentaps code with comments such as "Beginning of Customization" and "End of Customization" so that you will remember them when you resolve merge conflicts down the road. This process is both time-consuming and error-prone, so we highly recommend that you contribute back your changes to the core code base and keep your customizations and modifications as much as possible in a separate component in its own repository.