Hi,
I'm currently upgrading from 2.0.6 to 3.0.1 and I realize that it's not so funny that I need to inform all developers at once to upgrade to the 3.0 client.
It may be a nice thing if you can manage in future versions to do updates in a way that old versions are still able to work with the database.
We are managing this in our software (content management software with a smart client) by using a wrapper that decides by the requesting application version what business objects to invoke. Another way would be to simply use an URL containing the version number for requests to the server.
I know that it's not really "fun" to keep compatibility in database structures, but you may use views to "convert" new db table structures to compatible structures - this may introduce a huge performance decrease for old clients, but that way they will still work after a server update.
CU,
Sven
side by side server?
Moderator: SourceGear
When moving from Vault 2.0.x to Vault 3.0.x, changes occured not only in tables structures, triggers and stored procedures, but also in the protocol between client and server.
In the case of triggers, they were drastically modified to change the behavior to allow better concurrency in multi user configurations. Keeping the old triggers was just not feasible in this case.
Additionally, the protocol change ( which was modified to allow for better handling of checkout lists ) and the model for handling checkouts changed. The change was drastic enough that a 2.0.x client would never be able to work with a 3.0.x server.
We do realize the difficulties when rolling out a new version of software, and we go to extreme measures to make sure Client / Server compatibility is maintained within the same version. ( ie a Vault 3.0.1 client will work with a Vault 3.0.0 server. )
As you can see, this is a difficult problem. I'll log a request to see if there are ways to decrease the burden upon rollout. I cannot make any promises, but we'll see what we can do.
Thanks for the feedback.
In the case of triggers, they were drastically modified to change the behavior to allow better concurrency in multi user configurations. Keeping the old triggers was just not feasible in this case.
Additionally, the protocol change ( which was modified to allow for better handling of checkout lists ) and the model for handling checkouts changed. The change was drastic enough that a 2.0.x client would never be able to work with a 3.0.x server.
We do realize the difficulties when rolling out a new version of software, and we go to extreme measures to make sure Client / Server compatibility is maintained within the same version. ( ie a Vault 3.0.1 client will work with a Vault 3.0.0 server. )
As you can see, this is a difficult problem. I'll log a request to see if there are ways to decrease the burden upon rollout. I cannot make any promises, but we'll see what we can do.
Thanks for the feedback.
Jeff Clausius
SourceGear
SourceGear