Catherine must be notified of all changes to the component API.

For (small) API changes to methods or classes

• Create a new method and list the old one as depreatecd.
• Create a new class and list the old one as depreatecd.

The deprecated methods and classes may last for the duration of the next iteration. However, all of the deprecated APIs must be resolved by the end of the next iteration.

For larger changes to the API, e.g. major refactoring, initial development can be done using a new class in a new package, leaving the existing API in place.

When the new API is stable, notify Catherine, and then contact the other teams request that they move over to using the new API. Again, the old API becomes deprecated, and may last for the duration of the next iteration.

There are some cases where API changes cannot be managed using the deprecated mechanism. For example, changing the data objects may change the XML SOAP message, which will change any of the wsdl2Java generated classes.

In this situation, notify Catherine of the changes, and her team will act as the coordinatior, scheduling the change release to minimise the side effects on the other teams.

In order to help the other teams to migrate to the new API, it may be useful to use a separate CVS branch and modify their component to match your new API. The other teams can then either accept your changes, or use them as an example and do the changes themselves. This means that you can test that the new API is compatible with their component, and detect any problems before the new API is released.

-- DaveMorris - 03 Feb 2004