> While supporting a new HBase patch release version (e.g 2.4.1), if it turns out to be incompatible with existing HBase minor release profile (e.g profile 2.4), we might have to consider some extra steps.
What happened? If we broke something in a public or limited private interface between 2.4.0 and 2.4.1, we can fix it, and you'll be good again in 2.4.2 and forward. You could blacklist 2.4.1 in your build of the 2.4 compat module using the enforcer plugin if you like. If the break was a private interface, but it is a simple issue, like removal of a constant field, or removal of a method that's easy to put back for sake of compatibility, we can probably just put it back. By 'probably' I mean I would not be opposed to it but there's always the chance that someone would object. On Tue, Feb 16, 2021 at 4:07 AM Viraj Jasani <[email protected]> wrote: > Hi, > > While supporting a new HBase patch release version (e.g 2.4.1), if it turns > out to be incompatible with existing HBase minor release profile (e.g > profile 2.4), we might have to consider some extra steps. > > Proposals: > 1. Add a new profile for each compat module > 2. Profile with HBase minor version always support latest supported HBase > compat module and HBase patch release (e.g in our case, profile 2.4 uses > compat-module 2.4.1, and profile 2.4.0 uses compat module 2.4.0) > 3. We run jenkins tests only for latest minor release profiles (e.g with > profiles 2.4 and 2.4.0 in place, we run tests for profile 2.4 only, which > points to latest version 2.4.1) > > HBase profile to build compatibility examples: > > *Profile for HBase minor version:* > 2.1 (supports all 2.1.x releases), > 2.3 (supports all 2.3.x releases), > 2.4 (if we have profile 2.4.0, 2.4 profile supports 2.4.1+ releases and not > 2.4.0) > > *Profile for HBase patch version:* > 2.4.0 (supports only 2.4.0 release) > > Thoughts? > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
