Yeah, 5.0.1 is a good idea for the compat fix. I just wanted to make
sure that we had a clear list of all of the fixes for a 5.0.1 (and not
just the abstract idea of "we want to make one" ;)).
I can help spin a 5.0.1 if everyone else can help me figure out what
should go into it.
On 9/28/18 2:40 PM, Vincent Poon wrote:
Only one I can think of is PHOENIX-4849
<https://issues.apache.org/jira/browse/PHOENIX-4849>
But to your point, I think it's fine to hold off until a 5.1.0 - the
only thing is the timeline isn't entirely clear and a compat fix for
5.0.1 sounded urgent.
On Fri, Sep 28, 2018 at 8:29 AM Josh Elser <[email protected]
<mailto:[email protected]>> wrote:
Ok, cool. Thanks, Vincent!
Aside from the HBase 2.0.x compatibility fix, what other Phoenix bugs
should be pulled back for a 5.0.1?
My opinion is that if we don't know the distinct set of fixes for a
5.0.1, we should just take the tip of master and call it 5.1.0 instead.
On 9/27/18 12:16 AM, Vincent Poon wrote:
> You're right, Josh, I was mistaken, there was indeed a 5.0.0
release. But
> I meant the same as your last bit - branch off 5.0.0 and only put
in HBase
> 2.0.2 and critical fixes for 5.0.1.
>
> On Wed, Sep 26, 2018 at 6:40 PM Josh Elser <[email protected]
<mailto:[email protected]>> wrote:
>
>> No, Vincent, that is wrong. There *was* a 5.0.0-alpha release. Then,
>> there was a 5.0.0 release (not called alpha).
>>
>> To Thomas' original question: I don't think we need to keep 4.15 in
>> lock-step with 5.x, but if 5.x isn't ready for release for the same
>> reason 4.15 is not ready for release, then we should hold off on
another
>> 5.x (from the master branch).
>>
>> In a similar vein, we could also branch off of the 5.0.0 release and
>> cherry-pick back critical changes to make a proper 5.0.1 if a
5.1.0 is
>> still a ways off (as above)
>>
>> On 9/26/18 6:18 PM, Vincent Poon wrote:
>>> The 5.0.0 release apparently was an 'alpha'. I think we should
do a
>> 5.0.1
>>> which can work with HBase 2.0.2 and remove the 'alpha'.
>>> 5.0 has feature parity with 4.14.
>>> 5.1 would have feature parity with 4.15, the main addition being
>> splittable
>>> syscat
>>>
>>> On a sidenote, I've been planning a 4.14.1 release but was
waiting for
>> the
>>> CDH builds. It looks like CDH branches are no longer being
maintained
>> so I
>>> think I can just move forward with that. (btw we should clean
those up)
>>>
>>> If noone else is doing it, I can try doing the 5.0.1 release
>> concurrently.
>>>
>>> On Wed, Sep 26, 2018 at 3:01 PM Andrew Purtell
<[email protected] <mailto:[email protected]>>
>> wrote:
>>>
>>>> If possible please continue to release for one or more of the
HBase 1.x
>>>> code lines. I have a feeling the HBase 1.xes will be in
production for a
>>>> long time yet.
>>>>
>>>> On Wed, Sep 26, 2018 at 11:42 AM Thomas D'Silva
<[email protected] <mailto:[email protected]>
>>>
>>>> wrote:
>>>>
>>>>> Would we also release 4.15, or just a new 5.x release to
support HBase
>>>>> 2.0.1/2.0.2 ? PHOENIX-3534 has a few follow-up JIRAs that are
needed
>> for
>>>>> splittable system catalog.
>>>>>
>>>>> On Tue, Sep 25, 2018 at 7:56 PM, Josh Elser
<[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>>> On the user@phoenix list, Francis pointed out how Phoenix
5.0.0 only
>>>>>> works with HBase 2.0.0 and not 2.0.1 or 2.0.2. This is
pretty bad
>> given
>>>>> the
>>>>>> big fixes that went in since 2.0.0.
>>>>>>
>>>>>> What do folks think about a new 5.x release? Is it
worthwhile to bring
>>>>>> back a reduced set of commits and make a 5.0.1? Or just
release a
>> 5.1.0
>>>>> and
>>>>>> ask people to move to that instead?
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Andrew
>>>>
>>>> Words like orphans lost among the crosstalk, meaning torn from
truth's
>>>> decrepit hands
>>>> - A23, Crosstalk
>>>>
>>>
>>
>
