Thoughts on better compatibility for RTC client to server ?
Recently, the infrastructure team migrated the server up to GM version of RTC 1.0. Clients then have to ensure they are also updated to that version in order for things to work again.
The question is does server version always must "match" client version ? including any fixpacks ?
From a users perspective, when a version mis-match happens :
1. Error message displays: client/server incompatibility. Doesn't explain client update needed. (particularly if the infrastructure team failed to communicate)
2. Not understanding why its necessary.
3. What if user is working against different servers that have different version?
Thoughts? I like to know whether this will continue going forward....
The question is does server version always must "match" client version ? including any fixpacks ?
From a users perspective, when a version mis-match happens :
1. Error message displays: client/server incompatibility. Doesn't explain client update needed. (particularly if the infrastructure team failed to communicate)
2. Not understanding why its necessary.
3. What if user is working against different servers that have different version?
Thoughts? I like to know whether this will continue going forward....
3 answers
Hello Ying,
During development, the service interfaces and models were changing frequently, thus rendering older clients incompatible with up-to-date servers. Our goal however for maintenance releases and fixpacks is to maintain compatibility.
re: error messages - late in the development cycle we added changes to the wording to make it clearer what version was running on the server. Can you tell identify what the previous client version was?
re: supporting a single client communicating with servers of different versions: we don't currently have a mechanism in place that supports that but we hear the requirement. Making this work will require a looser coupling between client and server API and maintaining compatibility for service requests.
Ritchie Schacher
Jazz Server Development
During development, the service interfaces and models were changing frequently, thus rendering older clients incompatible with up-to-date servers. Our goal however for maintenance releases and fixpacks is to maintain compatibility.
re: error messages - late in the development cycle we added changes to the wording to make it clearer what version was running on the server. Can you tell identify what the previous client version was?
re: supporting a single client communicating with servers of different versions: we don't currently have a mechanism in place that supports that but we hear the requirement. Making this work will require a looser coupling between client and server API and maintaining compatibility for service requests.
Ritchie Schacher
Jazz Server Development
Hello Ying,
During development, the service interfaces and models were changing frequently, thus rendering older clients incompatible with up-to-date servers. Our goal however for maintenance releases and fixpacks is to maintain compatibility.
re: error messages - late in the development cycle we added changes to the wording to make it clearer what version was running on the server. Can you tell identify what the previous client version was?
re: supporting a single client communicating with servers of different versions: we don't currently have a mechanism in place that supports that but we hear the requirement. Making this work will require a looser coupling between client and server API and maintaining compatibility for service requests.
Ritchie Schacher
Jazz Server Development
Hi Ritchie -
The error message for incompatible versions are a bit better now. :)
Is there an work item/feature enhancement opened to address providing a client to communicate with servers of different versions? if so, do you have that number ?
Thanks much.
Ying
I don't think we have a bug open for general server compatibility. We
don't plan on supporting arbitrary combinations of clients and servers.
We will support 1.0 clients talking to 1.0.1 and 1.0.1.1 servers and we
support a 1.0.1 client talking to 1.0 servers.
We don't support a 2.0 client talking to a 1.* server or a 1.* client
talking to a 2.0 server.
-
Matt Lavin
Jazz Server Team
On Tue, 2009-02-24 at 21:07 +0000, ying1 wrote:
don't plan on supporting arbitrary combinations of clients and servers.
We will support 1.0 clients talking to 1.0.1 and 1.0.1.1 servers and we
support a 1.0.1 client talking to 1.0 servers.
We don't support a 2.0 client talking to a 1.* server or a 1.* client
talking to a 2.0 server.
-
Matt Lavin
Jazz Server Team
On Tue, 2009-02-24 at 21:07 +0000, ying1 wrote:
schacherwrote:
Hello Ying,
During development, the service interfaces and models were changing
frequently, thus rendering older clients incompatible with up-to-date
servers. Our goal however for maintenance releases and fixpacks is to
maintain compatibility.
re: error messages - late in the development cycle we added changes
to the wording to make it clearer what version was running on the
server. Can you tell identify what the previous client version was?
re: supporting a single client communicating with servers of
different versions: we don't currently have a mechanism in place that
supports that but we hear the requirement. Making this work will
require a looser coupling between client and server API and
maintaining compatibility for service requests.
Ritchie Schacher
Jazz Server Development
Hi Ritchie -
The error message for incompatible versions are a bit better now. :)
CRJAZ1241I There is a version mismatch for the
"com.ibm.team.process" service. The server version is
"6" while the client version is "8". Both client
and server version must match. Check the overall version of the
client using Help->About and ensure it is compatible with server
version "1.0.1" and build id
"I20081024-1335".
Is there an work item/feature enhancement opened to address providing
a client to communicate with servers of different versions? if so, do
you have that number ?
Thanks much.
Ying