I volunteer to develop and maintain a shim for 0.98 if nobody else will. If Phoenix is going to shim anyway for 1.2 vs 1.3 vs 1.4 vs ... then we need one for 0.98 for as long as we have 0.98 in production where I work, and I'm pessimistically estimating another year at least in some places. I think a year is too long to go without taking on at least a subset of new features.
We can have varying support for server-side features by shim. That is an interesting compromise. I'm thinking especially of local indexes. Note that at some point we (at my workplace) will only have 0.98 on the client side, so it doesn't matter if we are not supporting something on the server in the 0.98 shim as long as the client can drive the necessary query plans. The shims for things like server side support for local indexes could throw UnsupportedOperationException to signal that the feature(s) do not have the necessary server side support. In such a scenario if running a 1.3 client and a 0.98 server, for example, attempting to use such a feature would fail with runtime errors as expected and documented. If running a 0.98 client and a 1.3 server, for example, then there would be no problem. Like I said, if Phoenix is going to shim anyway to handle the differences in the various 1.x, which I think is a good idea, because there are going to be more I sadly promise you, then adding one more shim for 0.98 isn't onerous, if you have a volunteer to do the work, and you do. On Tue, Oct 10, 2017 at 10:12 AM, James Taylor <jamestay...@apache.org> wrote: > We won't need features ported over to the 0.98 branch, so I think it's > better all around if we just let the branches diverge rather than > implementing some kind of shim layer. We'll likely just need to do one or > two point releases on 0.98. We can do that from the 4.12-HBase-0.98 branch. > > Here are some thoughts I have on releases going forward: > - stop doing parallel releases on 0.98, 1.1, 1.2, and 1.3. > - stop committing across all branches > - if someone out there needs 1.1 and 1.2 release, they can volunteer as RM > and back port what they need. There's very little due diligence done on > those releases currently, so there's not a lot of value IMHO. > - continue forward with releases on master for 1.3. > - consider a shim layer when 1.4 releases land. > - target a 5.0 release as there are some big improvements coming to the > system catalog in PHOENIX-4198 and PHOENIX-3534. We need a volunteer for RM > - I've done 14 or so of our 17 releases so it's time for someone else to > step up. > > Thanks, > James > > On Mon, Oct 9, 2017 at 8:02 PM, Sergey Soldatov <sergeysolda...@gmail.com> > wrote: > > > Heh. I just remember that last time in August you said that you already > > migrating to more recent version of HBase and have no problems to > maintain > > 0.98 internally during for short time. As an alternative can we add > shims, > > so most of the difference in API can be grouped there and will be easy to > > maintain. Most of the changes are related to removing deprecated API in > > Put/Get/Delete and name changes like HAdmin -> Admin, so it may be > covered > > by a couple of support classes. After that it will be possible to get > > Phoenix compiled against 2.0 with some little changes related to shaded > > coprocessor API (possible may be added to shims as well) and tephra which > > is also using deprecated API. > > > > Thanks, > > Sergey > > > > On Tue, Oct 10, 2017 at 4:49 AM, Andrew Purtell <apurt...@apache.org> > > wrote: > > > > > Until we migrate our production at Salesforce off of 0.98 we will still > > > have to support 0.98 internally, and a number of our staff are > > committers, > > > so I suspect there will be adequate support for the 0.98 branch for > > another > > > couple of releases. > > > > > > On Mon, Oct 9, 2017 at 12:36 PM, Sergey Soldatov < > > sergeysolda...@gmail.com > > > > > > > wrote: > > > > > > > I remember that we discussed that a couple times already without any > > > final > > > > decision, so let me raise this question again. HBase 2.0 is getting > > close > > > > to the release and to support it we will need to do a lot of > > refactoring > > > in > > > > the code even just to get Phoenix compiled. And already we may start > to > > > > remove all deprecated API that was removed from 2.0 to minimize the > > > further > > > > changes that are directly related to 2.0 support. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Sergey > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > > - A23, Crosstalk > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
