Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Ayush Saxena]

We have had the last 2.x release. I don't think we did c-pick our
security issues into the last release either.
 Will start the EOL vote for the 2.x release line as we discussed earlier

-Ayush

On Sun, 21 Apr 2024 at 01:33, Chao Sun  wrote:
>
> Hi Cheng,
>
> Sorry for the long delay. I was distracted by other things.
>
> I just created RC0 for the Hive 2.3.10 release, and started a vote thread. 
> Please help to test if it looks good, especially from Spark side. Thanks!
>
> Best,
> Chao
>
>
>
> On Thu, Apr 18, 2024 at 5:15 AM Cheng Pan  wrote:
>>
>> Hi Chao,
>>
>> The Spark community is starting to discuss the 4.0 release[1], can we make 
>> the Hive 2.3.10 release happen soon?
>>
>> [1] https://lists.apache.org/thread/nxmvz2j7kp96otzlnl3kd277knlb6qgb
>>
>> Thanks,
>> Cheng Pan
>>
>> On 2024/01/17 17:50:37 Chao Sun wrote:
>> > Hi Ayush,
>> >
>> > I'm working on the last few commits to backport to the branch.
>> > Hopefully within 1-2 months I can start the release process. Our goal
>> > is to upgrade Hive 2.x before the Spark 4.0 release coming up mid this
>> > year.
>> >
>> > Chao
>> >
>> > On Tue, Jan 16, 2024 at 10:17 PM Ayush Saxena  wrote:
>> > >
>> > > Thanx everyone for the feedback, I have started a formal thread to mark 
>> > > 1.x
>> > > EOL. We can have one last release for 2.x as Chao mentioned, with some
>> > > required changes + our CVE's & get the release line marked as EOL then.
>> > >
>> > > @Chao Sun  Do let us know if you have a proposed
>> > > timeline for that.
>> > >
>> > > -Ayush
>> > >
>> > > On Wed, 17 Jan 2024 at 08:23, vihang karajgaonkar 
>> > > wrote:
>> > >
>> > > > I was confused about the subject line since it says 3.x as well along 
>> > > > with
>> > > > 1.x and 2.x. Does this discussion include all 1.x, 2.x and 3.x or just 
>> > > > 1.x
>> > > > and 2.x?
>> > > >
>> > > > I think it makes sense to EOL 1.x. Looks like 2.x is still being 
>> > > > maintained
>> > > > by Chao and I think we were backporting PRs to the 3.x line pretty 
>> > > > recently
>> > > > so I believe we should wait out for a release on Hive 3.x.
>> > > >
>> > > > Thanks,
>> > > > Vihang
>> > > >
>> > > > On Tue, Jan 16, 2024 at 3:40 PM Attila Turoczy
>> > > >  wrote:
>> > > >
>> > > > > Dear PMC's,
>> > > > >
>> > > > > Do we have a verdict / decision about this?
>> > > > >
>> > > > > -Attila
>> > > > >
>> > > > > On Wed, Jan 10, 2024 at 5:45 PM Chao Sun  wrote:
>> > > > >
>> > > > > > On Hive 2.x, I'm still preparing for another release 2.3.10 (Hive 
>> > > > > > 2.3
>> > > > > > branch is being actively maintained so far). Hopefully this will be
>> > > > > > the last release in the branch-2 line.
>> > > > > >
>> > > > > > +1 on making Hive 1 EOL for the time being.
>> > > > > >
>> > > > > > Chao
>> > > > > >
>> > > > > > On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
>> > > > > >  wrote:
>> > > > > > >
>> > > > > > > +1 for making both Hive 1&2 EOL
>> > > > > > >
>> > > > > > > -Sankar
>> > > > > > > -Original Message-
>> > > > > > > From: Attila Turoczy 
>> > > > > > > Sent: Wednesday, January 10, 2024 7:37 PM
>> > > > > > > To: dev@hive.apache.org
>> > > > > > > Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 
>> > > > > > > 3.x
>> > > > > > >
>> > > > > > > [You don't often get email from aturo...@cloudera.com.invalid. 
>> > > > > > > Learn
>> > > > > > why this is important at 
>> > > > > > https://aka.ms/LearnAboutSenderIdentification
>> > > > ]
>> > > > > > >
>> > > > > > > +1 for making it EOL for Hive 1 and Hive 2. I do not think these 
>> > > > > > > 2
>> > > > > > product
>> > > > > > > branches are relevant in 2023.
>> > > > > > >
>> > > > > > > -Attila
>> > > > > > >
>> > > > > > > On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko <
>> > > > dkuzme...@apache.org>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > +1 for marking Hive 1.x EOL
>> > > > > > > >
>> > > > > > > > Assuming no volunteers willing to take ownership of branch-2
>> > > > > > maintenance,
>> > > > > > > > +1 to declare it EOL as well.
>> > > > > > > >
>> > > > > > > > Regards,
>> > > > > > > > Denys
>> > > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> >
>>
>>
>>

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Chao Sun]

Hi Cheng,

Sorry for the long delay. I was distracted by other things.

I just created RC0 for the Hive 2.3.10 release, and started a vote thread.
Please help to test if it looks good, especially from Spark side. Thanks!

Best,
Chao



On Thu, Apr 18, 2024 at 5:15 AM Cheng Pan  wrote:

> Hi Chao,
>
> The Spark community is starting to discuss the 4.0 release[1], can we make
> the Hive 2.3.10 release happen soon?
>
> [1] https://lists.apache.org/thread/nxmvz2j7kp96otzlnl3kd277knlb6qgb
>
> Thanks,
> Cheng Pan
>
> On 2024/01/17 17:50:37 Chao Sun wrote:
> > Hi Ayush,
> >
> > I'm working on the last few commits to backport to the branch.
> > Hopefully within 1-2 months I can start the release process. Our goal
> > is to upgrade Hive 2.x before the Spark 4.0 release coming up mid this
> > year.
> >
> > Chao
> >
> > On Tue, Jan 16, 2024 at 10:17 PM Ayush Saxena  wrote:
> > >
> > > Thanx everyone for the feedback, I have started a formal thread to
> mark 1.x
> > > EOL. We can have one last release for 2.x as Chao mentioned, with some
> > > required changes + our CVE's & get the release line marked as EOL then.
> > >
> > > @Chao Sun  Do let us know if you have a proposed
> > > timeline for that.
> > >
> > > -Ayush
> > >
> > > On Wed, 17 Jan 2024 at 08:23, vihang karajgaonkar 
> > > wrote:
> > >
> > > > I was confused about the subject line since it says 3.x as well
> along with
> > > > 1.x and 2.x. Does this discussion include all 1.x, 2.x and 3.x or
> just 1.x
> > > > and 2.x?
> > > >
> > > > I think it makes sense to EOL 1.x. Looks like 2.x is still being
> maintained
> > > > by Chao and I think we were backporting PRs to the 3.x line pretty
> recently
> > > > so I believe we should wait out for a release on Hive 3.x.
> > > >
> > > > Thanks,
> > > > Vihang
> > > >
> > > > On Tue, Jan 16, 2024 at 3:40 PM Attila Turoczy
> > > >  wrote:
> > > >
> > > > > Dear PMC's,
> > > > >
> > > > > Do we have a verdict / decision about this?
> > > > >
> > > > > -Attila
> > > > >
> > > > > On Wed, Jan 10, 2024 at 5:45 PM Chao Sun  wrote:
> > > > >
> > > > > > On Hive 2.x, I'm still preparing for another release 2.3.10
> (Hive 2.3
> > > > > > branch is being actively maintained so far). Hopefully this will
> be
> > > > > > the last release in the branch-2 line.
> > > > > >
> > > > > > +1 on making Hive 1 EOL for the time being.
> > > > > >
> > > > > > Chao
> > > > > >
> > > > > > On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
> > > > > >  wrote:
> > > > > > >
> > > > > > > +1 for making both Hive 1&2 EOL
> > > > > > >
> > > > > > > -Sankar
> > > > > > > -Original Message-
> > > > > > > From: Attila Turoczy 
> > > > > > > Sent: Wednesday, January 10, 2024 7:37 PM
> > > > > > > To: dev@hive.apache.org
> > > > > > > Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x,
> 2.x, 3.x
> > > > > > >
> > > > > > > [You don't often get email from aturo...@cloudera.com.invalid.
> Learn
> > > > > > why this is important at
> https://aka.ms/LearnAboutSenderIdentification
> > > > ]
> > > > > > >
> > > > > > > +1 for making it EOL for Hive 1 and Hive 2. I do not think
> these 2
> > > > > > product
> > > > > > > branches are relevant in 2023.
> > > > > > >
> > > > > > > -Attila
> > > > > > >
> > > > > > > On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko <
> > > > dkuzme...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 for marking Hive 1.x EOL
> > > > > > > >
> > > > > > > > Assuming no volunteers willing to take ownership of branch-2
> > > > > > maintenance,
> > > > > > > > +1 to declare it EOL as well.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Denys
> > > > > > > >
> > > > > >
> > > > >
> > > >
> >
>
>
>
>

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Cheng Pan]

Hi Chao,

The Spark community is starting to discuss the 4.0 release[1], can we make the 
Hive 2.3.10 release happen soon?

[1] https://lists.apache.org/thread/nxmvz2j7kp96otzlnl3kd277knlb6qgb

Thanks,
Cheng Pan

On 2024/01/17 17:50:37 Chao Sun wrote:
> Hi Ayush,
> 
> I'm working on the last few commits to backport to the branch.
> Hopefully within 1-2 months I can start the release process. Our goal
> is to upgrade Hive 2.x before the Spark 4.0 release coming up mid this
> year.
> 
> Chao
> 
> On Tue, Jan 16, 2024 at 10:17 PM Ayush Saxena  wrote:
> >
> > Thanx everyone for the feedback, I have started a formal thread to mark 1.x
> > EOL. We can have one last release for 2.x as Chao mentioned, with some
> > required changes + our CVE's & get the release line marked as EOL then.
> >
> > @Chao Sun  Do let us know if you have a proposed
> > timeline for that.
> >
> > -Ayush
> >
> > On Wed, 17 Jan 2024 at 08:23, vihang karajgaonkar 
> > wrote:
> >
> > > I was confused about the subject line since it says 3.x as well along with
> > > 1.x and 2.x. Does this discussion include all 1.x, 2.x and 3.x or just 1.x
> > > and 2.x?
> > >
> > > I think it makes sense to EOL 1.x. Looks like 2.x is still being 
> > > maintained
> > > by Chao and I think we were backporting PRs to the 3.x line pretty 
> > > recently
> > > so I believe we should wait out for a release on Hive 3.x.
> > >
> > > Thanks,
> > > Vihang
> > >
> > > On Tue, Jan 16, 2024 at 3:40 PM Attila Turoczy
> > >  wrote:
> > >
> > > > Dear PMC's,
> > > >
> > > > Do we have a verdict / decision about this?
> > > >
> > > > -Attila
> > > >
> > > > On Wed, Jan 10, 2024 at 5:45 PM Chao Sun  wrote:
> > > >
> > > > > On Hive 2.x, I'm still preparing for another release 2.3.10 (Hive 2.3
> > > > > branch is being actively maintained so far). Hopefully this will be
> > > > > the last release in the branch-2 line.
> > > > >
> > > > > +1 on making Hive 1 EOL for the time being.
> > > > >
> > > > > Chao
> > > > >
> > > > > On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
> > > > >  wrote:
> > > > > >
> > > > > > +1 for making both Hive 1&2 EOL
> > > > > >
> > > > > > -Sankar
> > > > > > -Original Message-
> > > > > > From: Attila Turoczy 
> > > > > > Sent: Wednesday, January 10, 2024 7:37 PM
> > > > > > To: dev@hive.apache.org
> > > > > > Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x
> > > > > >
> > > > > > [You don't often get email from aturo...@cloudera.com.invalid. Learn
> > > > > why this is important at https://aka.ms/LearnAboutSenderIdentification
> > > ]
> > > > > >
> > > > > > +1 for making it EOL for Hive 1 and Hive 2. I do not think these 2
> > > > > product
> > > > > > branches are relevant in 2023.
> > > > > >
> > > > > > -Attila
> > > > > >
> > > > > > On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko <
> > > dkuzme...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 for marking Hive 1.x EOL
> > > > > > >
> > > > > > > Assuming no volunteers willing to take ownership of branch-2
> > > > > maintenance,
> > > > > > > +1 to declare it EOL as well.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Denys
> > > > > > >
> > > > >
> > > >
> > >
>  

Re: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Chao Sun]

Hi Ayush,

I'm working on the last few commits to backport to the branch.
Hopefully within 1-2 months I can start the release process. Our goal
is to upgrade Hive 2.x before the Spark 4.0 release coming up mid this
year.

Chao

On Tue, Jan 16, 2024 at 10:17 PM Ayush Saxena  wrote:
>
> Thanx everyone for the feedback, I have started a formal thread to mark 1.x
> EOL. We can have one last release for 2.x as Chao mentioned, with some
> required changes + our CVE's & get the release line marked as EOL then.
>
> @Chao Sun  Do let us know if you have a proposed
> timeline for that.
>
> -Ayush
>
> On Wed, 17 Jan 2024 at 08:23, vihang karajgaonkar 
> wrote:
>
> > I was confused about the subject line since it says 3.x as well along with
> > 1.x and 2.x. Does this discussion include all 1.x, 2.x and 3.x or just 1.x
> > and 2.x?
> >
> > I think it makes sense to EOL 1.x. Looks like 2.x is still being maintained
> > by Chao and I think we were backporting PRs to the 3.x line pretty recently
> > so I believe we should wait out for a release on Hive 3.x.
> >
> > Thanks,
> > Vihang
> >
> > On Tue, Jan 16, 2024 at 3:40 PM Attila Turoczy
> >  wrote:
> >
> > > Dear PMC's,
> > >
> > > Do we have a verdict / decision about this?
> > >
> > > -Attila
> > >
> > > On Wed, Jan 10, 2024 at 5:45 PM Chao Sun  wrote:
> > >
> > > > On Hive 2.x, I'm still preparing for another release 2.3.10 (Hive 2.3
> > > > branch is being actively maintained so far). Hopefully this will be
> > > > the last release in the branch-2 line.
> > > >
> > > > +1 on making Hive 1 EOL for the time being.
> > > >
> > > > Chao
> > > >
> > > > On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
> > > >  wrote:
> > > > >
> > > > > +1 for making both Hive 1&2 EOL
> > > > >
> > > > > -Sankar
> > > > > -Original Message-
> > > > > From: Attila Turoczy 
> > > > > Sent: Wednesday, January 10, 2024 7:37 PM
> > > > > To: dev@hive.apache.org
> > > > > Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x
> > > > >
> > > > > [You don't often get email from aturo...@cloudera.com.invalid. Learn
> > > > why this is important at https://aka.ms/LearnAboutSenderIdentification
> > ]
> > > > >
> > > > > +1 for making it EOL for Hive 1 and Hive 2. I do not think these 2
> > > > product
> > > > > branches are relevant in 2023.
> > > > >
> > > > > -Attila
> > > > >
> > > > > On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko <
> > dkuzme...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > +1 for marking Hive 1.x EOL
> > > > > >
> > > > > > Assuming no volunteers willing to take ownership of branch-2
> > > > maintenance,
> > > > > > +1 to declare it EOL as well.
> > > > > >
> > > > > > Regards,
> > > > > > Denys
> > > > > >
> > > >
> > >
> >

Re: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Ayush Saxena]

Thanx everyone for the feedback, I have started a formal thread to mark 1.x
EOL. We can have one last release for 2.x as Chao mentioned, with some
required changes + our CVE's & get the release line marked as EOL then.

@Chao Sun  Do let us know if you have a proposed
timeline for that.

-Ayush

On Wed, 17 Jan 2024 at 08:23, vihang karajgaonkar 
wrote:

> I was confused about the subject line since it says 3.x as well along with
> 1.x and 2.x. Does this discussion include all 1.x, 2.x and 3.x or just 1.x
> and 2.x?
>
> I think it makes sense to EOL 1.x. Looks like 2.x is still being maintained
> by Chao and I think we were backporting PRs to the 3.x line pretty recently
> so I believe we should wait out for a release on Hive 3.x.
>
> Thanks,
> Vihang
>
> On Tue, Jan 16, 2024 at 3:40 PM Attila Turoczy
>  wrote:
>
> > Dear PMC's,
> >
> > Do we have a verdict / decision about this?
> >
> > -Attila
> >
> > On Wed, Jan 10, 2024 at 5:45 PM Chao Sun  wrote:
> >
> > > On Hive 2.x, I'm still preparing for another release 2.3.10 (Hive 2.3
> > > branch is being actively maintained so far). Hopefully this will be
> > > the last release in the branch-2 line.
> > >
> > > +1 on making Hive 1 EOL for the time being.
> > >
> > > Chao
> > >
> > > On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
> > >  wrote:
> > > >
> > > > +1 for making both Hive 1&2 EOL
> > > >
> > > > -Sankar
> > > > -Original Message-
> > > > From: Attila Turoczy 
> > > > Sent: Wednesday, January 10, 2024 7:37 PM
> > > > To: dev@hive.apache.org
> > > > Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x
> > > >
> > > > [You don't often get email from aturo...@cloudera.com.invalid. Learn
> > > why this is important at https://aka.ms/LearnAboutSenderIdentification
> ]
> > > >
> > > > +1 for making it EOL for Hive 1 and Hive 2. I do not think these 2
> > > product
> > > > branches are relevant in 2023.
> > > >
> > > > -Attila
> > > >
> > > > On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko <
> dkuzme...@apache.org>
> > > > wrote:
> > > >
> > > > > +1 for marking Hive 1.x EOL
> > > > >
> > > > > Assuming no volunteers willing to take ownership of branch-2
> > > maintenance,
> > > > > +1 to declare it EOL as well.
> > > > >
> > > > > Regards,
> > > > > Denys
> > > > >
> > >
> >
>

Re: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[vihang karajgaonkar]

I was confused about the subject line since it says 3.x as well along with
1.x and 2.x. Does this discussion include all 1.x, 2.x and 3.x or just 1.x
and 2.x?

I think it makes sense to EOL 1.x. Looks like 2.x is still being maintained
by Chao and I think we were backporting PRs to the 3.x line pretty recently
so I believe we should wait out for a release on Hive 3.x.

Thanks,
Vihang

On Tue, Jan 16, 2024 at 3:40 PM Attila Turoczy
 wrote:

> Dear PMC's,
>
> Do we have a verdict / decision about this?
>
> -Attila
>
> On Wed, Jan 10, 2024 at 5:45 PM Chao Sun  wrote:
>
> > On Hive 2.x, I'm still preparing for another release 2.3.10 (Hive 2.3
> > branch is being actively maintained so far). Hopefully this will be
> > the last release in the branch-2 line.
> >
> > +1 on making Hive 1 EOL for the time being.
> >
> > Chao
> >
> > On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
> >  wrote:
> > >
> > > +1 for making both Hive 1&2 EOL
> > >
> > > -Sankar
> > > -Original Message-
> > > From: Attila Turoczy 
> > > Sent: Wednesday, January 10, 2024 7:37 PM
> > > To: dev@hive.apache.org
> > > Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x
> > >
> > > [You don't often get email from aturo...@cloudera.com.invalid. Learn
> > why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > +1 for making it EOL for Hive 1 and Hive 2. I do not think these 2
> > product
> > > branches are relevant in 2023.
> > >
> > > -Attila
> > >
> > > On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko 
> > > wrote:
> > >
> > > > +1 for marking Hive 1.x EOL
> > > >
> > > > Assuming no volunteers willing to take ownership of branch-2
> > maintenance,
> > > > +1 to declare it EOL as well.
> > > >
> > > > Regards,
> > > > Denys
> > > >
> >
>

Re: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Attila Turoczy]

Dear PMC's,

Do we have a verdict / decision about this?

-Attila

On Wed, Jan 10, 2024 at 5:45 PM Chao Sun  wrote:

> On Hive 2.x, I'm still preparing for another release 2.3.10 (Hive 2.3
> branch is being actively maintained so far). Hopefully this will be
> the last release in the branch-2 line.
>
> +1 on making Hive 1 EOL for the time being.
>
> Chao
>
> On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
>  wrote:
> >
> > +1 for making both Hive 1&2 EOL
> >
> > -Sankar
> > -Original Message-
> > From: Attila Turoczy 
> > Sent: Wednesday, January 10, 2024 7:37 PM
> > To: dev@hive.apache.org
> > Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x
> >
> > [You don't often get email from aturo...@cloudera.com.invalid. Learn
> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > +1 for making it EOL for Hive 1 and Hive 2. I do not think these 2
> product
> > branches are relevant in 2023.
> >
> > -Attila
> >
> > On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko 
> > wrote:
> >
> > > +1 for marking Hive 1.x EOL
> > >
> > > Assuming no volunteers willing to take ownership of branch-2
> maintenance,
> > > +1 to declare it EOL as well.
> > >
> > > Regards,
> > > Denys
> > >
>

Re: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Chao Sun]

On Hive 2.x, I'm still preparing for another release 2.3.10 (Hive 2.3
branch is being actively maintained so far). Hopefully this will be
the last release in the branch-2 line.

+1 on making Hive 1 EOL for the time being.

Chao

On Wed, Jan 10, 2024 at 8:10 AM Sankar Hariappan
 wrote:
>
> +1 for making both Hive 1&2 EOL
>
> -Sankar
> -Original Message-
> From: Attila Turoczy 
> Sent: Wednesday, January 10, 2024 7:37 PM
> To: dev@hive.apache.org
> Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x
>
> [You don't often get email from aturo...@cloudera.com.invalid. Learn why this 
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> +1 for making it EOL for Hive 1 and Hive 2. I do not think these 2 product
> branches are relevant in 2023.
>
> -Attila
>
> On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko 
> wrote:
>
> > +1 for marking Hive 1.x EOL
> >
> > Assuming no volunteers willing to take ownership of branch-2 maintenance,
> > +1 to declare it EOL as well.
> >
> > Regards,
> > Denys
> >

RE: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Sankar Hariappan]

+1 for making both Hive 1&2 EOL

-Sankar
-Original Message-
From: Attila Turoczy  
Sent: Wednesday, January 10, 2024 7:37 PM
To: dev@hive.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[You don't often get email from aturo...@cloudera.com.invalid. Learn why this 
is important at https://aka.ms/LearnAboutSenderIdentification ]

+1 for making it EOL for Hive 1 and Hive 2. I do not think these 2 product
branches are relevant in 2023.

-Attila

On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko 
wrote:

> +1 for marking Hive 1.x EOL
>
> Assuming no volunteers willing to take ownership of branch-2 maintenance,
> +1 to declare it EOL as well.
>
> Regards,
> Denys
>

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Attila Turoczy]

+1 for making it EOL for Hive 1 and Hive 2. I do not think these 2 product
branches are relevant in 2023.

-Attila

On Wed, Jan 10, 2024 at 12:59 PM Denys Kuzmenko 
wrote:

> +1 for marking Hive 1.x EOL
>
> Assuming no volunteers willing to take ownership of branch-2 maintenance,
> +1 to declare it EOL as well.
>
> Regards,
> Denys
>

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Denys Kuzmenko]

+1 for marking Hive 1.x EOL

Assuming no volunteers willing to take ownership of branch-2 maintenance, +1 to 
declare it EOL as well.

Regards,
Denys

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Stamatis Zampetakis]

+1 for marking Hive 1.x EOL.

I will also take the opportunity to ask again for Hive 2.x. Are there
people willing to take on the maintenance of the branch-2 line? The
people who take on the maintenance of the release line should (as a
bare minimum) ensure that all CVEs (existing and new ones) are
backported in a timely manner and cut new releases once this happens.
If there are no volunteers to take on this task then the PMC should
also vote for closing this branch.

Best,
Stamatis

On Wed, Jan 10, 2024 at 12:48 AM Ayush Saxena  wrote:
>
> I will start a vote to mark Hive 1.x EOL next week. Let me know if
> anyone has concerns around it.
>
> The main reason to mark a release line EOL is: if we have a CVE & if
> we don't release all the active lines with the fix we can't announce
> that & the PMC would be flagged every quarter for delaying the
> process, So, sooner or later we need to find a way to reduce the
> number of active release lines.
>
> -Ayush
>
> On Fri, 29 Jul 2022 at 01:35, Chao Sun  wrote:
> >
> > Hive 2.x is still being used by other projects like Spark and Iceberg,
> > and periodically there are bug fixes & CVE fixes coming into the
> > branch. So I would suggest keeping it alive for a bit longer (maybe
> > after 2.3.10/11 release) until the other projects are ready to move
> > away from it (which could take some significant efforts).
> >
> > Chao
> >
> > On Thu, Jul 28, 2022 at 5:51 AM Ayush Saxena  wrote:
> > >
> > > +1, to start EOL vote for 1.x, and we can keep a doc or a reference in the
> > > Hive Wiki/Website to mark the lines EOL
> > >
> > > Sharing thoughts about the other release lines.
> > > Though there were assertions that we have a lot of users on 2.x & 3.x
> > > lines, I don't think marking these lines as  EOL will impact them that
> > > badly.
> > > Marking a release line seems to be a Dev agreement that we as the
> > > developers aren't putting enough efforts now maintaining these branches 
> > > and
> > > they aren't very up to date.
> > >
> > > Quoting the example from Hadoop. Hadoop 3.1.x line is marked as EOL and
> > > still almost every second person on Hadoop 3.x line is on a heavily 
> > > patched
> > > version of 3.1.x, and from the other half still a bunch of them are on 2.x
> > > family, out of which only 2.10.x isn't EOL. Side note: As of today Hive in
> > > master branch also depends on an unstable EOL version of hadoop, that is
> > > 3.1.0(Upgrade in progress)
> > >
> > > From the stability point of view, I agree with Stamatis that 4.x in alpha
> > > stage is still better than a bunch of previous releases in many aspects,
> > > and supporting older releases will just slow down the chances of
> > > adaptability of the new 4.x.
> > > If we see the git history even of these old branches, the frequency of
> > > commits are even too low, so I don't think most of the
> > > developers/committers aren't putting efforts maintaining these
> > > branches.(Subjective Opinion)
> > >
> > > IMO, We should consider marking 1.x & 2.x as EOL, Resolve upgrade issues
> > > mentioned for 3.x->4.x and once resolved, if that doesn't require any
> > > changes on 3.x line and everyone is happy then mark that even as EOL or
> > > else have a last bridge release for this branch to move to 4.x
> > >
> > > Just my 2 cents.
> > >
> > > -Ayush
> > >
> > >
> > >
> > > On Mon, 25 Jul 2022 at 19:38, Stamatis Zampetakis  
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > In the last exchanges there was a general consensus to EOL Hive 1.X but 
> > > > no
> > > > additional action.
> > > > I believe the next step would be to start a VOTE and move forward with 
> > > > an
> > > > official announcement.
> > > >
> > > > I think it would be helpful for the end-users to know which releases are
> > > > supported and which are strongly discouraged.
> > > > The Hadoop community keeps this information in their wiki [1].
> > > >
> > > > Although, I am still not convinced that we should encourage users to use
> > > > the older release lines (2.X, 3.X) we can postpone the decision for the
> > > > time being and proceed just for 1.X.
> > > >
> > > > Best,
> > > > Stamatis
> > > >
> > > > [1]
> > > >
> > > > https://cwiki.apache.org/confluence/display/HADOOP/EOL+%28End-of-life%29+Release+Branches
> > > >
> > > > On Tue, May 10, 2022 at 2:51 PM Stamatis Zampetakis 
> > > > wrote:
> > > >
> > > > > Thanks everyone for sharing your thoughts. I am happy to see so many
> > > > > people involved in the discussion.
> > > > >
> > > > > I would say that the current 4.0.0-alpha-1 is better in many aspects 
> > > > > than
> > > > > previous stable releases, although this might be a bit subjective.
> > > > >
> > > > > I am afraid that if we keep supporting older releases it will take too
> > > > > much time till people start using the 4.x.
> > > > > Having real deployments of Hive 4 is the only way to go from alpha to
> > > > > stable releases with confidence.
> > > > >
> > > > > I checked the download statistics for Hive

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Ayush Saxena]

I will start a vote to mark Hive 1.x EOL next week. Let me know if
anyone has concerns around it.

The main reason to mark a release line EOL is: if we have a CVE & if
we don't release all the active lines with the fix we can't announce
that & the PMC would be flagged every quarter for delaying the
process, So, sooner or later we need to find a way to reduce the
number of active release lines.

-Ayush

On Fri, 29 Jul 2022 at 01:35, Chao Sun  wrote:
>
> Hive 2.x is still being used by other projects like Spark and Iceberg,
> and periodically there are bug fixes & CVE fixes coming into the
> branch. So I would suggest keeping it alive for a bit longer (maybe
> after 2.3.10/11 release) until the other projects are ready to move
> away from it (which could take some significant efforts).
>
> Chao
>
> On Thu, Jul 28, 2022 at 5:51 AM Ayush Saxena  wrote:
> >
> > +1, to start EOL vote for 1.x, and we can keep a doc or a reference in the
> > Hive Wiki/Website to mark the lines EOL
> >
> > Sharing thoughts about the other release lines.
> > Though there were assertions that we have a lot of users on 2.x & 3.x
> > lines, I don't think marking these lines as  EOL will impact them that
> > badly.
> > Marking a release line seems to be a Dev agreement that we as the
> > developers aren't putting enough efforts now maintaining these branches and
> > they aren't very up to date.
> >
> > Quoting the example from Hadoop. Hadoop 3.1.x line is marked as EOL and
> > still almost every second person on Hadoop 3.x line is on a heavily patched
> > version of 3.1.x, and from the other half still a bunch of them are on 2.x
> > family, out of which only 2.10.x isn't EOL. Side note: As of today Hive in
> > master branch also depends on an unstable EOL version of hadoop, that is
> > 3.1.0(Upgrade in progress)
> >
> > From the stability point of view, I agree with Stamatis that 4.x in alpha
> > stage is still better than a bunch of previous releases in many aspects,
> > and supporting older releases will just slow down the chances of
> > adaptability of the new 4.x.
> > If we see the git history even of these old branches, the frequency of
> > commits are even too low, so I don't think most of the
> > developers/committers aren't putting efforts maintaining these
> > branches.(Subjective Opinion)
> >
> > IMO, We should consider marking 1.x & 2.x as EOL, Resolve upgrade issues
> > mentioned for 3.x->4.x and once resolved, if that doesn't require any
> > changes on 3.x line and everyone is happy then mark that even as EOL or
> > else have a last bridge release for this branch to move to 4.x
> >
> > Just my 2 cents.
> >
> > -Ayush
> >
> >
> >
> > On Mon, 25 Jul 2022 at 19:38, Stamatis Zampetakis  wrote:
> >
> > > Hi all,
> > >
> > > In the last exchanges there was a general consensus to EOL Hive 1.X but no
> > > additional action.
> > > I believe the next step would be to start a VOTE and move forward with an
> > > official announcement.
> > >
> > > I think it would be helpful for the end-users to know which releases are
> > > supported and which are strongly discouraged.
> > > The Hadoop community keeps this information in their wiki [1].
> > >
> > > Although, I am still not convinced that we should encourage users to use
> > > the older release lines (2.X, 3.X) we can postpone the decision for the
> > > time being and proceed just for 1.X.
> > >
> > > Best,
> > > Stamatis
> > >
> > > [1]
> > >
> > > https://cwiki.apache.org/confluence/display/HADOOP/EOL+%28End-of-life%29+Release+Branches
> > >
> > > On Tue, May 10, 2022 at 2:51 PM Stamatis Zampetakis 
> > > wrote:
> > >
> > > > Thanks everyone for sharing your thoughts. I am happy to see so many
> > > > people involved in the discussion.
> > > >
> > > > I would say that the current 4.0.0-alpha-1 is better in many aspects 
> > > > than
> > > > previous stable releases, although this might be a bit subjective.
> > > >
> > > > I am afraid that if we keep supporting older releases it will take too
> > > > much time till people start using the 4.x.
> > > > Having real deployments of Hive 4 is the only way to go from alpha to
> > > > stable releases with confidence.
> > > >
> > > > I checked the download statistics for Hive releases [1], [2] for the 
> > > > past
> > > > month and the results show that the vast majority of downloads are for
> > > > older releases.
> > > > I am not posting the stats here since I am not sure if this would 
> > > > violate
> > > > some policies. Hive committers can access the stats using their ASF
> > > > credentials.
> > > > To some degree this is expected but at the same time problematic given
> > > the
> > > > number of open issues which affect older releases.
> > > >
> > > > I would definitely like to have multiple maintenance branches with high
> > > > quality standards but I don't think there are enough active committers 
> > > > in
> > > > the project to successfully maintain those.
> > > > The https://github.com/mr3project/hive-mr3 repo may be a great f

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Chao Sun]

Hive 2.x is still being used by other projects like Spark and Iceberg,
and periodically there are bug fixes & CVE fixes coming into the
branch. So I would suggest keeping it alive for a bit longer (maybe
after 2.3.10/11 release) until the other projects are ready to move
away from it (which could take some significant efforts).

Chao

On Thu, Jul 28, 2022 at 5:51 AM Ayush Saxena  wrote:
>
> +1, to start EOL vote for 1.x, and we can keep a doc or a reference in the
> Hive Wiki/Website to mark the lines EOL
>
> Sharing thoughts about the other release lines.
> Though there were assertions that we have a lot of users on 2.x & 3.x
> lines, I don't think marking these lines as  EOL will impact them that
> badly.
> Marking a release line seems to be a Dev agreement that we as the
> developers aren't putting enough efforts now maintaining these branches and
> they aren't very up to date.
>
> Quoting the example from Hadoop. Hadoop 3.1.x line is marked as EOL and
> still almost every second person on Hadoop 3.x line is on a heavily patched
> version of 3.1.x, and from the other half still a bunch of them are on 2.x
> family, out of which only 2.10.x isn't EOL. Side note: As of today Hive in
> master branch also depends on an unstable EOL version of hadoop, that is
> 3.1.0(Upgrade in progress)
>
> From the stability point of view, I agree with Stamatis that 4.x in alpha
> stage is still better than a bunch of previous releases in many aspects,
> and supporting older releases will just slow down the chances of
> adaptability of the new 4.x.
> If we see the git history even of these old branches, the frequency of
> commits are even too low, so I don't think most of the
> developers/committers aren't putting efforts maintaining these
> branches.(Subjective Opinion)
>
> IMO, We should consider marking 1.x & 2.x as EOL, Resolve upgrade issues
> mentioned for 3.x->4.x and once resolved, if that doesn't require any
> changes on 3.x line and everyone is happy then mark that even as EOL or
> else have a last bridge release for this branch to move to 4.x
>
> Just my 2 cents.
>
> -Ayush
>
>
>
> On Mon, 25 Jul 2022 at 19:38, Stamatis Zampetakis  wrote:
>
> > Hi all,
> >
> > In the last exchanges there was a general consensus to EOL Hive 1.X but no
> > additional action.
> > I believe the next step would be to start a VOTE and move forward with an
> > official announcement.
> >
> > I think it would be helpful for the end-users to know which releases are
> > supported and which are strongly discouraged.
> > The Hadoop community keeps this information in their wiki [1].
> >
> > Although, I am still not convinced that we should encourage users to use
> > the older release lines (2.X, 3.X) we can postpone the decision for the
> > time being and proceed just for 1.X.
> >
> > Best,
> > Stamatis
> >
> > [1]
> >
> > https://cwiki.apache.org/confluence/display/HADOOP/EOL+%28End-of-life%29+Release+Branches
> >
> > On Tue, May 10, 2022 at 2:51 PM Stamatis Zampetakis 
> > wrote:
> >
> > > Thanks everyone for sharing your thoughts. I am happy to see so many
> > > people involved in the discussion.
> > >
> > > I would say that the current 4.0.0-alpha-1 is better in many aspects than
> > > previous stable releases, although this might be a bit subjective.
> > >
> > > I am afraid that if we keep supporting older releases it will take too
> > > much time till people start using the 4.x.
> > > Having real deployments of Hive 4 is the only way to go from alpha to
> > > stable releases with confidence.
> > >
> > > I checked the download statistics for Hive releases [1], [2] for the past
> > > month and the results show that the vast majority of downloads are for
> > > older releases.
> > > I am not posting the stats here since I am not sure if this would violate
> > > some policies. Hive committers can access the stats using their ASF
> > > credentials.
> > > To some degree this is expected but at the same time problematic given
> > the
> > > number of open issues which affect older releases.
> > >
> > > I would definitely like to have multiple maintenance branches with high
> > > quality standards but I don't think there are enough active committers in
> > > the project to successfully maintain those.
> > > The https://github.com/mr3project/hive-mr3 repo may be a great fit for
> > an
> > > upcoming ASF Hive release.
> > > However, according to what Sungwoo said, this seems more like a new
> > > maintenance branch rather than a continuation of Hive 3.
> > > Moving towards this direction would certainly require more time from all
> > > of us.
> > >
> > > Lastly, it seems that there are some issues preventing people from using
> > > 4.0.0-alpha-1.
> > > As Peter already mentioned these issues are probably release blockers and
> > > it should be taken into account in the next Hive 4 release.
> > > The thread about the next steps after 4.0.0-alpha-1 [3] is the perfect
> > > place to discuss those.
> > > For those with certain demands around Hive 4, pl

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Ayush Saxena]

+1, to start EOL vote for 1.x, and we can keep a doc or a reference in the
Hive Wiki/Website to mark the lines EOL

Sharing thoughts about the other release lines.
Though there were assertions that we have a lot of users on 2.x & 3.x
lines, I don't think marking these lines as  EOL will impact them that
badly.
Marking a release line seems to be a Dev agreement that we as the
developers aren't putting enough efforts now maintaining these branches and
they aren't very up to date.

Quoting the example from Hadoop. Hadoop 3.1.x line is marked as EOL and
still almost every second person on Hadoop 3.x line is on a heavily patched
version of 3.1.x, and from the other half still a bunch of them are on 2.x
family, out of which only 2.10.x isn't EOL. Side note: As of today Hive in
master branch also depends on an unstable EOL version of hadoop, that is
3.1.0(Upgrade in progress)

>From the stability point of view, I agree with Stamatis that 4.x in alpha
stage is still better than a bunch of previous releases in many aspects,
and supporting older releases will just slow down the chances of
adaptability of the new 4.x.
If we see the git history even of these old branches, the frequency of
commits are even too low, so I don't think most of the
developers/committers aren't putting efforts maintaining these
branches.(Subjective Opinion)

IMO, We should consider marking 1.x & 2.x as EOL, Resolve upgrade issues
mentioned for 3.x->4.x and once resolved, if that doesn't require any
changes on 3.x line and everyone is happy then mark that even as EOL or
else have a last bridge release for this branch to move to 4.x

Just my 2 cents.

-Ayush



On Mon, 25 Jul 2022 at 19:38, Stamatis Zampetakis  wrote:

> Hi all,
>
> In the last exchanges there was a general consensus to EOL Hive 1.X but no
> additional action.
> I believe the next step would be to start a VOTE and move forward with an
> official announcement.
>
> I think it would be helpful for the end-users to know which releases are
> supported and which are strongly discouraged.
> The Hadoop community keeps this information in their wiki [1].
>
> Although, I am still not convinced that we should encourage users to use
> the older release lines (2.X, 3.X) we can postpone the decision for the
> time being and proceed just for 1.X.
>
> Best,
> Stamatis
>
> [1]
>
> https://cwiki.apache.org/confluence/display/HADOOP/EOL+%28End-of-life%29+Release+Branches
>
> On Tue, May 10, 2022 at 2:51 PM Stamatis Zampetakis 
> wrote:
>
> > Thanks everyone for sharing your thoughts. I am happy to see so many
> > people involved in the discussion.
> >
> > I would say that the current 4.0.0-alpha-1 is better in many aspects than
> > previous stable releases, although this might be a bit subjective.
> >
> > I am afraid that if we keep supporting older releases it will take too
> > much time till people start using the 4.x.
> > Having real deployments of Hive 4 is the only way to go from alpha to
> > stable releases with confidence.
> >
> > I checked the download statistics for Hive releases [1], [2] for the past
> > month and the results show that the vast majority of downloads are for
> > older releases.
> > I am not posting the stats here since I am not sure if this would violate
> > some policies. Hive committers can access the stats using their ASF
> > credentials.
> > To some degree this is expected but at the same time problematic given
> the
> > number of open issues which affect older releases.
> >
> > I would definitely like to have multiple maintenance branches with high
> > quality standards but I don't think there are enough active committers in
> > the project to successfully maintain those.
> > The https://github.com/mr3project/hive-mr3 repo may be a great fit for
> an
> > upcoming ASF Hive release.
> > However, according to what Sungwoo said, this seems more like a new
> > maintenance branch rather than a continuation of Hive 3.
> > Moving towards this direction would certainly require more time from all
> > of us.
> >
> > Lastly, it seems that there are some issues preventing people from using
> > 4.0.0-alpha-1.
> > As Peter already mentioned these issues are probably release blockers and
> > it should be taken into account in the next Hive 4 release.
> > The thread about the next steps after 4.0.0-alpha-1 [3] is the perfect
> > place to discuss those.
> > For those with certain demands around Hive 4, please reply to [3] and
> > include any specific JIRAs that need to be in the scope of the next
> release.
> >
> > Best,
> > Stamatis
> >
> > [1] https://logging1-he-de.apache.org/stats/
> > [2] https://repository.apache.org/#central-stat
> > [3] https://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
> >
> >
> > On Tue, May 10, 2022 at 10:55 AM Sungwoo Park  wrote:
> >
> >> We maintain our own fork of Hive 3 because we are not always adding new
> >> commits to the tip of the branch. To backport a new patch, sometimes we
> >> have to add new commits between existing commits, 

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Stamatis Zampetakis]

Hi all,

In the last exchanges there was a general consensus to EOL Hive 1.X but no
additional action.
I believe the next step would be to start a VOTE and move forward with an
official announcement.

I think it would be helpful for the end-users to know which releases are
supported and which are strongly discouraged.
The Hadoop community keeps this information in their wiki [1].

Although, I am still not convinced that we should encourage users to use
the older release lines (2.X, 3.X) we can postpone the decision for the
time being and proceed just for 1.X.

Best,
Stamatis

[1]
https://cwiki.apache.org/confluence/display/HADOOP/EOL+%28End-of-life%29+Release+Branches

On Tue, May 10, 2022 at 2:51 PM Stamatis Zampetakis 
wrote:

> Thanks everyone for sharing your thoughts. I am happy to see so many
> people involved in the discussion.
>
> I would say that the current 4.0.0-alpha-1 is better in many aspects than
> previous stable releases, although this might be a bit subjective.
>
> I am afraid that if we keep supporting older releases it will take too
> much time till people start using the 4.x.
> Having real deployments of Hive 4 is the only way to go from alpha to
> stable releases with confidence.
>
> I checked the download statistics for Hive releases [1], [2] for the past
> month and the results show that the vast majority of downloads are for
> older releases.
> I am not posting the stats here since I am not sure if this would violate
> some policies. Hive committers can access the stats using their ASF
> credentials.
> To some degree this is expected but at the same time problematic given the
> number of open issues which affect older releases.
>
> I would definitely like to have multiple maintenance branches with high
> quality standards but I don't think there are enough active committers in
> the project to successfully maintain those.
> The https://github.com/mr3project/hive-mr3 repo may be a great fit for an
> upcoming ASF Hive release.
> However, according to what Sungwoo said, this seems more like a new
> maintenance branch rather than a continuation of Hive 3.
> Moving towards this direction would certainly require more time from all
> of us.
>
> Lastly, it seems that there are some issues preventing people from using
> 4.0.0-alpha-1.
> As Peter already mentioned these issues are probably release blockers and
> it should be taken into account in the next Hive 4 release.
> The thread about the next steps after 4.0.0-alpha-1 [3] is the perfect
> place to discuss those.
> For those with certain demands around Hive 4, please reply to [3] and
> include any specific JIRAs that need to be in the scope of the next release.
>
> Best,
> Stamatis
>
> [1] https://logging1-he-de.apache.org/stats/
> [2] https://repository.apache.org/#central-stat
> [3] https://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
>
>
> On Tue, May 10, 2022 at 10:55 AM Sungwoo Park  wrote:
>
>> We maintain our own fork of Hive 3 because we are not always adding new
>> commits to the tip of the branch. To backport a new patch, sometimes we
>> have to add new commits between existing commits, update earlier commits,
>> and so on. This makes it impractical to keep adding new patches only to the
>> tip of the branch while reverting commits if necessary. Maintaining the
>> Hive 3 branch would mean frequent force-updates, which might produce more
>> problems. (If this is not an issue, we could try to completely rebuild the
>> Hive 3 branch.)
>>
>> I hope the Apache community can make a concerted effort to figure out
>> what patches to include in Hive 3. For us, the challenge was 1) to decide
>> which patch to include; 2) to figure out its dependencies if any; 3) to
>> resolve conflicts. Testing was also another source of pain.
>>
>> Thanks,
>>
>> --- Sungwoo
>>
>>
>>
>>
>>
>> On Tue, May 10, 2022 at 4:26 PM Peter Vary  wrote:
>>
>>> When we were brainstorming about the future of the Hive 3 branch with
>>> Zoltan Haindrich, he mentioned this letter:
>>> https://lists.apache.org/thread/by9ppc2z8oqdzpqotzv5bs34yrxrd84l
>>>
>>> I think Sungwoo Park and his team makes a huge effort to maintain this
>>> branch, and maybe it would be better to help them do this inside the Apache
>>> Hive project. They should not need to maintain their own branch if there is
>>> no particular reason behind it, or we can remove those blockers. This could
>>> be beneficial for every Hive user who still uses Hive 3.
>>>
>>> @Sungwoo: Do you have any specific reason to keep you own fork of Hive 3?
>>>
>>> That would mean we could have a much better Hive 3.x branch than we have
>>> now.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>>
>>> On 2022. May 10., at 8:40, Battula, Brahma Reddy <
>>> bbatt...@visa.com.INVALID> wrote:
>>>
>>> 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 t

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Stamatis Zampetakis]

Thanks everyone for sharing your thoughts. I am happy to see so many people
involved in the discussion.

I would say that the current 4.0.0-alpha-1 is better in many aspects than
previous stable releases, although this might be a bit subjective.

I am afraid that if we keep supporting older releases it will take too much
time till people start using the 4.x.
Having real deployments of Hive 4 is the only way to go from alpha to
stable releases with confidence.

I checked the download statistics for Hive releases [1], [2] for the past
month and the results show that the vast majority of downloads are for
older releases.
I am not posting the stats here since I am not sure if this would violate
some policies. Hive committers can access the stats using their ASF
credentials.
To some degree this is expected but at the same time problematic given the
number of open issues which affect older releases.

I would definitely like to have multiple maintenance branches with high
quality standards but I don't think there are enough active committers in
the project to successfully maintain those.
The https://github.com/mr3project/hive-mr3 repo may be a great fit for an
upcoming ASF Hive release.
However, according to what Sungwoo said, this seems more like a new
maintenance branch rather than a continuation of Hive 3.
Moving towards this direction would certainly require more time from all of
us.

Lastly, it seems that there are some issues preventing people from using
4.0.0-alpha-1.
As Peter already mentioned these issues are probably release blockers and
it should be taken into account in the next Hive 4 release.
The thread about the next steps after 4.0.0-alpha-1 [3] is the perfect
place to discuss those.
For those with certain demands around Hive 4, please reply to [3] and
include any specific JIRAs that need to be in the scope of the next release.

Best,
Stamatis

[1] https://logging1-he-de.apache.org/stats/
[2] https://repository.apache.org/#central-stat
[3] https://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj


On Tue, May 10, 2022 at 10:55 AM Sungwoo Park  wrote:

> We maintain our own fork of Hive 3 because we are not always adding new
> commits to the tip of the branch. To backport a new patch, sometimes we
> have to add new commits between existing commits, update earlier commits,
> and so on. This makes it impractical to keep adding new patches only to the
> tip of the branch while reverting commits if necessary. Maintaining the
> Hive 3 branch would mean frequent force-updates, which might produce more
> problems. (If this is not an issue, we could try to completely rebuild the
> Hive 3 branch.)
>
> I hope the Apache community can make a concerted effort to figure out what
> patches to include in Hive 3. For us, the challenge was 1) to decide which
> patch to include; 2) to figure out its dependencies if any; 3) to resolve
> conflicts. Testing was also another source of pain.
>
> Thanks,
>
> --- Sungwoo
>
>
>
>
>
> On Tue, May 10, 2022 at 4:26 PM Peter Vary  wrote:
>
>> When we were brainstorming about the future of the Hive 3 branch with
>> Zoltan Haindrich, he mentioned this letter:
>> https://lists.apache.org/thread/by9ppc2z8oqdzpqotzv5bs34yrxrd84l
>>
>> I think Sungwoo Park and his team makes a huge effort to maintain this
>> branch, and maybe it would be better to help them do this inside the Apache
>> Hive project. They should not need to maintain their own branch if there is
>> no particular reason behind it, or we can remove those blockers. This could
>> be beneficial for every Hive user who still uses Hive 3.
>>
>> @Sungwoo: Do you have any specific reason to keep you own fork of Hive 3?
>>
>> That would mean we could have a much better Hive 3.x branch than we have
>> now.
>>
>> What do you think?
>>
>> Thanks,
>> Peter
>>
>>
>>
>> On 2022. May 10., at 8:40, Battula, Brahma Reddy <
>> bbatt...@visa.com.INVALID> wrote:
>>
>> 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"  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  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,

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Peter Vary]

When we were brainstorming about the future of the Hive 3 branch with Zoltan 
Haindrich, he mentioned this letter: 
https://lists.apache.org/thread/by9ppc2z8oqdzpqotzv5bs34yrxrd84l 


I think Sungwoo Park and his team makes a huge effort to maintain this branch, 
and maybe it would be better to help them do this inside the Apache Hive 
project. They should not need to maintain their own branch if there is no 
particular reason behind it, or we can remove those blockers. This could be 
beneficial for every Hive user who still uses Hive 3.

@Sungwoo: Do you have any specific reason to keep you own fork of Hive 3?

That would mean we could have a much better Hive 3.x branch than we have now.

What do you think?

Thanks,
Peter



> On 2022. May 10., at 8:40, Battula, Brahma Reddy  
> wrote:
> 
> 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"  > 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  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 
>>  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  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
>>>  
>>> 

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Battula, Brahma Reddy]

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"  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  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 
 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  
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
>>
>

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Peter Vary]

Shall we put the core/shading to the blocker for 4.0.0?
Do we have a jira for it?

Thanks Sun Chao for bringing this up!

Peter

On Mon, May 9, 2022, 19:21 Chao Sun  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  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 
> 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://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
> >>
> >
>

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Chao Sun]

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  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 
>  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  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://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
>>
>

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Peter Vary]

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 
>  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  > 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://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj 
> 
> 

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Alessandro Solimando]

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  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://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
>
>

[DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Stamatis Zampetakis]

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://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj