IIRC, the guidance is that 4.14 should work back to 4.12. We're talking about minor releases in this case, not bugfix. Every bugfix release should be compatible within the current minor release. This is one of the tenants of https://semver.org/

You should not have issues going to 5.0.0, but I don't know of anyone who has explicitly tested this. You should proceed with caution.

On 6/14/19 2:07 AM, Vova Galchenko wrote:
Hey Josh,

thanks for getting back to me. The current Phoenix version we're on is 4.14.1. Do I understand correctly that the Phoenix community intends to provide data compatibility at least two versions back? Does this intention apply across major version boundaries? More specifically, does it imply that data produced by 4.14.1 is intended to be compatible with 4.14.2 and 5.0.0?

Thank you.

vova

On Wed, Jun 12, 2019 at 1:18 PM Josh Elser <els...@apache.org <mailto:els...@apache.org>> wrote:

    What version of Phoenix 4 are you coming from?

    Of note, if you're lagging far behind, you'll get bit by the column
    encoding turning on by default in 4.10 [1]

    In general, before we update the system catalog table, we take a
    snapshot of it, so you can roll back (although this would be
    manual). In
    terms of testing as a community, we only do testing back two releases.
    After that, your mileage may vary.

    - Josh

    [1] https://phoenix.apache.org/columnencoding.html

    On 6/11/19 9:02 PM, Vova Galchenko wrote:
     > Hello Phoenix Users List!
     >
     > We at Box are thinking about the upgrade story from Phoenix 4 to
    5. As
     > part of that, we'd like to understand if these Phoenix versions
    write
     > data in formats compatible with each other. In other words,
    suppose we
     > have an HBase 1.4 cluster used by Phoenix 4. Can I shut
    everything down,
     > upgrade HBase to 2.0 and Phoenix to 5, start everything up again,
    and
     > expect to preserve the integrity of the data stored in the original
     > cluster? If not, is there guidance for what the upgrade process
    might
     > look like?
     >
     > Thanks,
     >
     > vova

Reply via email to