Yeah, we have the same situation. It's essentially a schema
compatibility integer.
Perhaps a major and minor version would work where major versions
have to match and minor versions are insignificant (e.g., for bug
fixes)
Yeah, that is also what I am thinking. At first I thought of hav
On 01/07/2008, at 6:39 AM, Andrew Lindesay wrote:
Hello Florijan;
I use a "compatibility integer" that gets matched between the client
and the server's base-endpoint. This works well for the situation
where you have one or two pieces of (in my case JSON-RPC) client
software, but as the n
On Jun 30, 2008, at 12:00 PM, Florijan Stamenkovic wrote:
I am about to implement a JavaClient focused versioning system to
evaluate the compatibility between the client and the server
during client startup. It is something that is a requirement in
our situation (JC + JBND apps, separated
Hello Florijan;
I use a "compatibility integer" that gets matched between the client
and the server's base-endpoint. This works well for the situation
where you have one or two pieces of (in my case JSON-RPC) client
software, but as the number of different pieces of client software
grows
I am about to implement a JavaClient focused versioning system to
evaluate the compatibility between the client and the server
during client startup. It is something that is a requirement in
our situation (JC + JBND apps, separated server client projects etc).
What kinds of things are you t
On Jun 30, 2008, at 10:28 AM, Florijan Stamenkovic wrote:
Hi all,
I am about to implement a JavaClient focused versioning system to
evaluate the compatibility between the client and the server during
client startup. It is something that is a requirement in our
situation (JC + JBND apps,
Hi all,
I am about to implement a JavaClient focused versioning system to
evaluate the compatibility between the client and the server during
client startup. It is something that is a requirement in our
situation (JC + JBND apps, separated server client projects etc).
Also note that this
