What server versions does an RTC SDK application work with?
We have a standalone Java application that uses the RTC SDK to access an RTC server. What server versions does our RTC SDK application work with? For example, say that our application uses the RTC 4.0.3 SDK. Will it be able to connect to an RTC 4.0.2 server? What about connecting to an RTC 4.0.4 server once RTC 4.0.4 becomes available?
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
Ralph Schoon (63.5k●3●36●46)
| answered Jul 09 '13, 6:00 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I chose to provide a more detailed answer of my findings here: http://rsjazz.wordpress.com/2013/07/09/new-version-and-now-experiences-with-sdk-and-plain-java-api-across-tool-versions/
Geoff Alexander selected this answer as the correct answer
|
2 other answers
There is no guarantee of upward compatibility with the RTC SDK, and the SDK is offered 'as is' without warranties or support of any kind. Depending on what is changed between versions, there is a good chance that 4.0.3 SDK will connect to a 4.0.4 server. However, some of your code may fail if the SDK changed between versions.
I would recommend keeping the SDK on the same version of your server to ensure you don't run into any issues with compatibility. |
|
Ralph Schoon (63.5k●3●36●46)
| answered Jul 09 '13, 2:40 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jul 09 '13, 3:59 a.m.
As I see it RTC has (at least) the following Java APIs
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.
I also have a number of applications and extensions, written to the 2.0 api libraries
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.