Welcome to the Jazz Community Forum
3.0.1 incompatible with 3.0 ?!

Is it really true that 3.0.1 is incompatible with 3.0? For various
reasons i had to upgrade my client to 3.0.1 and now i cannot connect
anymore to one RTC server which is still at level 3.0 with a pop-up
complaining that the two versions are not compatible. While it was
already extremely surprising that there was no backlevel support in 2.0,
it seems uncomprehensible that not even sub-minor versions are
compatible: Forcing upgrades of clients and server in lock-step and
forcing to have multiple clients installed so you can interact with
multiple servers of (slightly) different levels is hard to swallow ....
-michael-
PS: at the very least the release notes could state this incompatability
issue ...
reasons i had to upgrade my client to 3.0.1 and now i cannot connect
anymore to one RTC server which is still at level 3.0 with a pop-up
complaining that the two versions are not compatible. While it was
already extremely surprising that there was no backlevel support in 2.0,
it seems uncomprehensible that not even sub-minor versions are
compatible: Forcing upgrades of clients and server in lock-step and
forcing to have multiple clients installed so you can interact with
multiple servers of (slightly) different levels is hard to swallow ....
-michael-
PS: at the very least the release notes could state this incompatability
issue ...
5 answers

It's not a good idea to assume the version number was chosen to communicate scope of change or degree of compatibility in any meaningful way. Or even to uniquely identify it. IBM is funny like that.
This is especially puzzling with the products built on eclipse, which has a really solid version numbering scheme. Why 3.0 and 3.0 iFix were both 3.0.0 with differing datestamps appended to the version I'll never know.
One would assume that 3.0.1 would contain bugfixes alone, but it's actually a pretty huge change. One would think it would have been given 3.1 or even 4.0.
This is especially puzzling with the products built on eclipse, which has a really solid version numbering scheme. Why 3.0 and 3.0 iFix were both 3.0.0 with differing datestamps appended to the version I'll never know.
One would assume that 3.0.1 would contain bugfixes alone, but it's actually a pretty huge change. One would think it would have been given 3.1 or even 4.0.

My understanding is that a 3.0 RTC Eclipse-plugin can be used with a
3.0.1 server (so you can upgrade your servers from 3.0 to 3.0.1 without
requiring your users to upgrade their Eclipse clients), but a 3.0.1 RTC
Eclipse-plugin cannot be used against a 3.0 server. So you'll need to
keep around a 3.0 RTC Eclipse client to access your 3.0 servers.
For folks interested in some of the the challenges with the version
numbering: RTC is part of the CLM 2011 solution containing RTC, RQM, and
RRC. In order to prevent confusion about what versions are part of the
improved integrations provided by the 2011 CLM solution, it was
desirable for the June 2011 releases of RTC, RQM, and RRC to have
aligned version numbers. From an RTC perspective, a 3.1 number would
have been better (or even 3.5), but this was the first 3.x release for
RQM and RRC, and calling the first 3.x release RQM and RRC 3.1 or 3.5
was thought by some to be confusing, so 3.0.1 was selected as a compromise.
(Personally, I would have preferred having the June 2011 release be 3.1,
but as long as the version numbers were aligned between RTC, RQM, and
RRC, I could live with the 3.0.1 choice).
Cheers,
Geoff
On 6/27/2011 1:28 PM, Michael Steiner wrote:
3.0.1 server (so you can upgrade your servers from 3.0 to 3.0.1 without
requiring your users to upgrade their Eclipse clients), but a 3.0.1 RTC
Eclipse-plugin cannot be used against a 3.0 server. So you'll need to
keep around a 3.0 RTC Eclipse client to access your 3.0 servers.
For folks interested in some of the the challenges with the version
numbering: RTC is part of the CLM 2011 solution containing RTC, RQM, and
RRC. In order to prevent confusion about what versions are part of the
improved integrations provided by the 2011 CLM solution, it was
desirable for the June 2011 releases of RTC, RQM, and RRC to have
aligned version numbers. From an RTC perspective, a 3.1 number would
have been better (or even 3.5), but this was the first 3.x release for
RQM and RRC, and calling the first 3.x release RQM and RRC 3.1 or 3.5
was thought by some to be confusing, so 3.0.1 was selected as a compromise.
(Personally, I would have preferred having the June 2011 release be 3.1,
but as long as the version numbers were aligned between RTC, RQM, and
RRC, I could live with the 3.0.1 choice).
Cheers,
Geoff
On 6/27/2011 1:28 PM, Michael Steiner wrote:
Is it really true that 3.0.1 is incompatible with 3.0? For various
reasons i had to upgrade my client to 3.0.1 and now i cannot connect
anymore to one RTC server which is still at level 3.0 with a pop-up
complaining that the two versions are not compatible. While it was
already extremely surprising that there was no backlevel support in 2.0,
it seems uncomprehensible that not even sub-minor versions are
compatible: Forcing upgrades of clients and server in lock-step and
forcing to have multiple clients installed so you can interact with
multiple servers of (slightly) different levels is hard to swallow ....
-michael-
PS: at the very least the release notes could state this incompatability
issue ...

On 06/27/2011 05:23 PM, jburns wrote:
The version offered in IM as upgrade to 3.0.1, presumably the final
published version.
-michael-
msteinerwrote:
Is it really true that 3.0.1 is incompatible with 3.0?
Are you using a final (published) RTC 3.0.1 client against a 3.0
server? Or do you have a 3.0.1 milestone build?
The version offered in IM as upgrade to 3.0.1, presumably the final
published version.
-michael-