You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by David Harvey <sy...@gmail.com> on 2018/09/05 15:18:20 UTC
Minor version changes and server/client compatibility
We have needed to do a couple of simple bug fixes to ignite proper, where
there is no change to interfaces or internode communications. When we do
this, we end up with these choices:
- Coordinate client and server code bases so that they are in lock
step. Tedious with multiple clusters and test/dev versions.
- Force the prior version number on the new builds, making it more
tedious to understand what versions we are running.
A standard practice would to ignore the last field in the version when
doing a compatibility test, e.g., 2.5.0 and 2.5.foobar would be considered
compatible. Is there some reason ignite requires and exact match?
How do other Ignite users handle this problem?
Thanks,
-DH
Re: Minor version changes and server/client compatibility
Posted by Dmitriy Pavlov <dp...@gmail.com>.
Hi Taras, thank you for your comments. I totally agree.
пн, 10 сент. 2018 г. в 17:14, Taras Ledkov <tl...@gridgain.com>:
> Dmitry, my short comment about maintains compatibilities.
>
> Ignite should be maintains (according to review checklist [1]):
>
> - binary compatibility for persistence store between minor releases;
> - JDBC and ODBC and thin client protocol forward and backward
> compatibility between two consecutive minor releases;
>
> [1]. https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>
>
> On 10.09.2018 16:29, Dmitriy Pavlov wrote:
> > Hi David,
> >
> > Ignite does not maintain compatibility between different versions. It is
> > not easy to do in a general case.
> >
> > But if you would like to hear about it from other users, you can also ask
> > on the user list.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> >
> > ср, 5 сент. 2018 г. в 18:18, David Harvey <sy...@gmail.com>:
> >
> >> We have needed to do a couple of simple bug fixes to ignite proper,
> where
> >> there is no change to interfaces or internode communications. When we
> do
> >> this, we end up with these choices:
> >>
> >> - Coordinate client and server code bases so that they are in lock
> >> step. Tedious with multiple clusters and test/dev versions.
> >> - Force the prior version number on the new builds, making it more
> >> tedious to understand what versions we are running.
> >>
> >> A standard practice would to ignore the last field in the version when
> >> doing a compatibility test, e.g., 2.5.0 and 2.5.foobar would be
> considered
> >> compatible. Is there some reason ignite requires and exact match?
> >> How do other Ignite users handle this problem?
> >>
> >> Thanks,
> >>
> >> -DH
> >>
>
> --
> Taras Ledkov
> Mail-To: tledkov@gridgain.com
>
>
Re: Minor version changes and server/client compatibility
Posted by Taras Ledkov <tl...@gridgain.com>.
Dmitry, my short comment about maintains compatibilities.
Ignite should be maintains (according to review checklist [1]):
- binary compatibility for persistence store between minor releases;
- JDBC and ODBC and thin client protocol forward and backward
compatibility between two consecutive minor releases;
[1]. https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
On 10.09.2018 16:29, Dmitriy Pavlov wrote:
> Hi David,
>
> Ignite does not maintain compatibility between different versions. It is
> not easy to do in a general case.
>
> But if you would like to hear about it from other users, you can also ask
> on the user list.
>
> Sincerely,
> Dmitriy Pavlov
>
>
> ср, 5 сент. 2018 г. в 18:18, David Harvey <sy...@gmail.com>:
>
>> We have needed to do a couple of simple bug fixes to ignite proper, where
>> there is no change to interfaces or internode communications. When we do
>> this, we end up with these choices:
>>
>> - Coordinate client and server code bases so that they are in lock
>> step. Tedious with multiple clusters and test/dev versions.
>> - Force the prior version number on the new builds, making it more
>> tedious to understand what versions we are running.
>>
>> A standard practice would to ignore the last field in the version when
>> doing a compatibility test, e.g., 2.5.0 and 2.5.foobar would be considered
>> compatible. Is there some reason ignite requires and exact match?
>> How do other Ignite users handle this problem?
>>
>> Thanks,
>>
>> -DH
>>
--
Taras Ledkov
Mail-To: tledkov@gridgain.com
Re: Minor version changes and server/client compatibility
Posted by Dmitriy Pavlov <dp...@gmail.com>.
Hi David,
Ignite does not maintain compatibility between different versions. It is
not easy to do in a general case.
But if you would like to hear about it from other users, you can also ask
on the user list.
Sincerely,
Dmitriy Pavlov
ср, 5 сент. 2018 г. в 18:18, David Harvey <sy...@gmail.com>:
> We have needed to do a couple of simple bug fixes to ignite proper, where
> there is no change to interfaces or internode communications. When we do
> this, we end up with these choices:
>
> - Coordinate client and server code bases so that they are in lock
> step. Tedious with multiple clusters and test/dev versions.
> - Force the prior version number on the new builds, making it more
> tedious to understand what versions we are running.
>
> A standard practice would to ignore the last field in the version when
> doing a compatibility test, e.g., 2.5.0 and 2.5.foobar would be considered
> compatible. Is there some reason ignite requires and exact match?
> How do other Ignite users handle this problem?
>
> Thanks,
>
> -DH
>