Agree to Peter and sunchao..
Even we are using the hive 3.x, we might contribute on bugfixes.
Even I am +1 on 1.x EOL as it's hard to maintain so many releases and time to
user's migrate to 2.x and 3.x.
On 09/05/22, 10:51 PM, "Chao Sun" <sunc...@apache.org> wrote:
Agree to Peter above. I know quite a few projects such as Spark,
Iceberg and Trino/Presto are depending on Hive 2.x and 3.x, and
periodically they may need new fixes in these. Upgrading them to use
4.x seems not an option for now since the core classified artifact has
been removed and the shading issue has to be solved before they can
consume the new jar.
On Mon, May 9, 2022 at 4:10 AM Peter Vary <pv...@cloudera.com> wrote:
>
> Hi Team,
>
> My experience with the Iceberg community shows that there are some
sizeable userbase around Hive 2.x. I have seen patches, contributions to Hive
2.3.x branches, and the tests are in much better shape there.
>
> I would definitely vote for EOL Hive 1.x, but until we have a stable 4.x,
I would be cautious about slashing 2.x, 3.x branches.
>
> Just my 2 cents.
>
> Peter
>
> On 2022. May 9., at 10:51, Alessandro Solimando
<alessandro.solima...@gmail.com> wrote:
>
> Hi Stamatis,
> thanks for bringing up this topic, I basically agree on everything you
wrote.
>
> I just wanted to add that this kind of proposal might sound harsh,
because in many contexts upgrading is a complex process, but it's in nobody's
interest to keep release branches that are missing important fixes/improvements
and that might not meet the quality standards that people expect, as mentioned.
>
> Since we don't have yet a stable 4.x release (only alpha for now) we
might want to keep supporting the 3.x branch until the first 4.x stable release
and EOL < 3.x branches, WDYT?
>
> Best regards,
> Alessandro
>
> On Fri, 6 May 2022 at 23:14, Stamatis Zampetakis <zabe...@gmail.com>
wrote:
>>
>> Hi all,
>>
>> The current master has many critical bug fixes as well as important
performance improvements that are not backported (and most likely never will)
to the maintenance branches.
>>
>> Backporting changes from master usually requires adapting the code and
tests in questions making it a non-trivial and time consuming task.
>>
>> The ASF bylaws require PMCs to deliver high quality software which
satisfy certain criteria. Cutting new releases from maintenance branches with
known critical bugs is not compliant with the ASF.
>>
>> CI is unstable in all maintenance branches making the quality of a
release questionable and merging new PRs rather difficult. Enabling and running
it frequently in all maintenance branches would require a big amount of
resources on top of what we already need for master.
>>
>> History has shown that it is very difficult or impossible to properly
maintain multiple release branches for Hive.
>>
>> I think it would be to the best interest of the project if the PMC
decided to drop support for maintenance branches and focused on releasing
exclusively from master.
>>
>> This mail is related to the discussion about the release cadence [1]
since it would certainly help making Hive releases more regular. I decided to
start a separate thread to avoid mixing multiple topics together.
>>
>> Looking forward to your thoughts.
>>
>> Best,
>> Stamatis
>>
>> [1]
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fn245dd23kb2v3qrrfp280w3pto89khxj&data=05%7C01%7Cbbattula%40visa.com%7Ccba1383657724a00f0bb08da31e069bc%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637877137169408371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X3BJyzgALXZVnjmd2PzbLrOi4lXMHxEQa8KwA1Pz7BQ%3D&reserved=0
>>
>
