views:

49

answers:

1

We have a product that has multiple extensions that ship with it, each of which has its own version number. (Specifically we have a xulrunner application with multiple extensions). The extension manager for xulrunner provides an update functionality so that it will call a function any time the version number of that extension has increased. This gives us a hook to do any necessary clean-up with the update.

However, it has become very hard to come up with a good way to keep track of which extensions need a version number increase and which ones have remained essentially unchanged. The best process we can imagine is 1) adding upfront work when closing tickets (every single ticket can have a series of flags designating which extensions need to be modified)
2) writing queries that search for which tickets have changes to an extension since the last release for a particular client and 3) Updating extension version numbers throughout the product

This all seems tedious both during development and at release time - and error-prone. Any suggestions?

A: 

It sounds like you're leaning towards using your work tickets to identify the changes to your extensions. I wonder if you should be looking at it the other way around and using your Version Control system to identify where changes were made.

Your Version History should provide you all the insight you need on what has changed based on the changes actually made and released. It will also provide a certain amount of auditing that the scope of change expected matches the scope of change completed.

Based on that information, you can implement your version change decisions.

Dan