What server versions does an RTC SDK application work with?
I found the Rational solution for Collaborative Lifecycle Management 4.0.4 InfoCenter page (https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.jazz.install.doc/topics/c_n-1.html&scope=null) that describes Jazz CLM client / server compatibility. However, it doesn't mention standalone Java applications using the RTC SDK.
Accepted answer
2 other answers
I would recommend keeping the SDK on the same version of your server to ensure you don't run into any issues with compatibility.
- Plain Java Client Libraries - for stand alone Java applications
- The RTC client side SDK - for Eclipse client and other eclipse based extensions
-
The RTC server side SDK - for server side extensions
You might want to look at https://rsjazz.wordpress.com/2013/03/14/what-apis-are-available-for-rtc-and-what-can-you-extend/
With respect to compatibility my experience so far:
1. Running Plain Java or Eclipse Client applications inherits the N-1 compatibility that is attempted, if it was achievable. I have run 3.0.1.1 client library applications against 4.0.x servers.
2. RTC Client Side SDK deployed in a client inherit the N-1 compatibility if it was achieved.
Upgrading Extensions and runtime compatibility
I have upgraded my extensions from 3.x to 4.x over the years. My experience so far is that it always was a smooth transition. I have seen very little changes in the API, some few deprecated classes. the only changes I have seen are new API's and in 3.x permission aware read access. It is necessary to think about unavailable read access in 3.x or higher and make sure the extension does not run in an environment that violates the assumptions made when it was created.
I would expect if the plug-in dependencies and feature dependencies are modeled with minimal or no version dependencies, it might be even possible to deploy an extension created for 3.x into 4.x without any changes. I have not tried that however.
I usually set up a new development workspace (I am now working with 4.0.1 and looking into going to 4.0.3 see http://rsjazz.wordpress.com/2013/02/28/setting-up-rational-team-concert-for-api-development/ ). I usually load or import my extensions created with older SDK versions and make sure they do compile, debug or test them quickly. I would create the update site from this version and deploy it. However, this might not be necessary at all. You just have to make sure that the dependencies are not version aware or accept newer versions of the SDK.
I would expect issues if you use the RTC 4.0.3 APIs/SDK against lower versions (e.g. 4.0). The client would not be able to connect. If you have version dependencies in your plugins, I would expect load problems.
Comments
Just to support what I said above, I just built the Build On State Change Participant from the RTC Extensions Workshop with 3.0.1.1 and deployed it in 4.0.3 client and server.
It works like a charm.
I also ran a workitem creation Plain Java Client Libraries app from within 3.0.1.1 against a RTC 4.0.3 server.
That also worked with no problems at all.
I also have a number of applications and extensions, written to the 2.0 api libraries
some of the binaries work unchanged, some work unmodified, altho recompiled to 3.0.1.1 thru 4.0.3.
these are all tested UPward (3.0 client talking to 3.0 or 4.0 server).. never downward.