Re: [infinispan-dev] Keeping formats compatible
On 11 July 2013 17:26, Galder Zamarreño <galder(a)redhat.com> wrote:
Too many paralell discussions in this email thread… changing title…
+1
On Jul 11, 2013, at 12:14 PM, Sanne Grinovero
<sanne(a)infinispan.org> wrote:
> Thanks Galder for opening the JIRA; but I wonder if we actually have a way out.
>
> 5.3.0.Final was released already, so if you want to "fix" its format
> to be compatible with 5.2 in a minor patch version - probably 5.3.1 -
> then that would break compatibility with 5.3.0 which is maybe even
> worse.
Hold on till we've figured out the cause… and if you're a rigt, a potential fix
could be investigated to make 5.3.0 and 5.3.1 compatible...
Right.
> Probably the lesser evil is to clearly warn about this and suggest an
> external dump; this way we also save some work as we could drop the
> existing CacheStore implementation and move on.. the saved dev time
> could be spent on tests to make sure this problem won't occur again as
> it clearly is a major problem if it slips into a released version
> without being spotted on time.
When we started investigating rolling upgrades we played with the idea of having a
serialized format that's readable between different versions and we created [1]. I
actually created some branches to investigate the feasibility of adding such tests: [2, 3,
4, 5, 6], and of course found incompatibilities. This idea was abandoned and instead we
decided on a Hot Rod based mechanism to transfer the data from one cluster to the other.
That was my understanding as well, and why I suggest to not give too
much importance to the CacheStore: we somehow agreed that this wasn't
expected to work. To be clear, I was not agreeing on that but since
that was the consensus based on what we can practically do I'm just
sticking to it now: we decided it would be incompatible.
Such tests could be added, but there needs to be a limit on how far
we want to be backwards compatible with. IOW, trying for Infinispan 5.3 to be backwards
compatible with 4.0 would be a lot of work. The minimum req would possibly be that
we're backwards compatible between minors.
+1 If we make this as an external tool released with each version to
migrate from the previous version, then people can "chain" them up to
migrate across longer version gaps. This could eventually evolve in a
set of helper scripts which help migrate from any version (since we
start this practice) to any other version.
This is something we can try to start imposing from 6.0 onwards. It's a good moment
to start doing it, at the beginning of a major release.
+1 Which again implies dropping older version's compatibility.
Cheers,
Sanne
[1] https://issues.jboss.org/browse/ISPN-2034
[2] https://github.com/galderz/infinispan/tree/archive/t_2034_40x
[3] https://github.com/galderz/infinispan/tree/archive/t_2034_41x
[4] https://github.com/galderz/infinispan/tree/archive/t_2034_42x
[5] https://github.com/galderz/infinispan/tree/archive/t_2034_50x
[6] https://github.com/galderz/infinispan/tree/archive/t_2034_51x
>
> Cheers,
> Sanne
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev