Note that the first poc has been put together and is available here:

https://test.kuali.org/svn/rice/branches/versioning-poc-1-1-0-br

Notes and docs on version compatibility poc's can be found here:

https://wiki.kuali.org/display/KULRICE/Version+Compatibility+Proof-of-Concepts

Based on discussion with Jason, second round of poc will include the following;

1) We decided that we would only version services when it is necessary to do so and on every "major" release.
2) Work on moving data types out to separate module from remote api? This could allow for reuse in things like xml import/export.
– Allows us to use same compatibility principles for xml import/export!
– maybe instead, move all of this stuff back into the API module?
3) Modify all DTOs such that they have the appropriate JAXB annotations on them
– also need to fix AttributeSetDTO, it's schema is messed up
4) Move the adapter out of a "version-specific" location
– also move to impl module
5) Update the namespaces such that everything under group is generated under the same namespace (including versions)
– should put DTOs in a different namespace, to help allow for reuse elsewhere
– could create a separate "type" module
6) Do a proof of concept with an actual version change example
7) Try a "compatible" change
8) Work on way to publish web service with a specific wsdl
– generate wsdls so they are on the classpath as well
9) Create a poc on one of the "kim type" services to show invocation from newer client to older client

Branch is:

https://test.kuali.org/svn/rice/branches/versioning-poc2-1-1-0-br

Added Jason as a watcher

Just committed first version of the "framework" module for kim which has some code for the KimTypeService and the KimGroupTypeService.

Have the general framework in place and committed for an app that wants to publish a KIM GroupTypeService (though still need to implement the code that converts between types). Next up is the following:

1) Create a test client that I can fire up in a test harness to test publishing of the aforementioned service.
2) Come up with a strategy for implementing the server-side which calls back into the older client-side versions. Not sure what this is going to look like yet, probably need to play out a scenario of three different versions of the service and 3 different clients (each with a different version of a GroupTypeService) all being invoked from the server. Could decorator pattern come in handy here to create a "chain" of conversions for a particular service call?

This was done long ago with the help of Jason and Travis.

Closing since these items are now in the release notes.