The client zip will be packaged by and downloadable from the server. Therefore the bundled client zip will always be compatible. But this does not ensure that connecting clients are compatible. If possible we should perform some sort of version handshake when connecting via the API. Perhaps the login method could pass version information or something in that arena...
(11:00:27 AM) ccrouch: joseph, mazz: where did this discussion get on http://jira.rhq-project.org/browse/RHQ-2200 yesterday (11:00:40 AM) ccrouch: is this something we can support with just a serverside change in the future? (11:06:49 AM) mazz: ccrouch: we agreed to push 2200 out
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2200
mass move off of the qa rhq_triage queue, these are dev subtasks
best to add the version checking in RemoteClient since this will allow for the version checking to be performed not only for our CLI but also any remote client built using our Java API. The code to do this version checking should be done somewhere in RemoteClient.doConnect().
git commit to master: 66fd59f the remote client will not connect to the server if the server is not supported. for this commit, "not supported" means the server and cli/remote client aren't the same version. We can later change this behavior if we deem it necessary. For example, maybe we can change it so if the MAJOR version is different we abort, otherwise let it connect. Or maybe if the MAJOR and MINOR is the same but only the PATCH version is different, we let it connect. Right now, if ANYTHING is different (major/minor or patch version #), the client won't connect. Note that if you want to force the client to connect and ignore the version check, you can do this. You can force the connect to success and skip the version check if, in your rhq-cli-env.sh, you add this: RHQ_CLI_ADDITIONAL_JAVA_OPTS=-Drhq.client.version-check=false If you wrote your own Java client, in the VM that is running RemoteClient, you can set that system property as shown above (to the value of false) to skip the check
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.