Hi Stamatis,

That is the standard practice to create minor version release for bugfixes. 
Many upstream projects follow that same strategy, check Iceberg for example.

Regards,
Denys

On 2024/04/18 07:49:59 Stamatis Zampetakis wrote:
> The 4.0.0 release was quite recent so I assume we don't have major
> breaking changes in there at the moment so we could cut the release
> directly from master as soon as we want. HIVE-28166 is already merged
> so we could aim to cut 4.1.0 as soon as HIVE-28190 goes in.
> 
> The experience shows that we are not very good at maintaining multiple
> release branches so in general I would prefer to focus on releasing
> only from master for the time being. Hive is a quite mature project so
> in principle breaking changes should be rather rare which gives us a
> bit of margin. I think a scheme where we backport less and release
> more is preferable.
> 
> Best,
> Stamatis
> 
> On Wed, Apr 17, 2024 at 9:56 AM Ayush Saxena <ayush...@gmail.com> wrote:
> >
> > Hi Stamatis,
> > The plan is to have a release line cut from the branch-4.0, So, we plan to 
> > pull in some critical bug fixes & improvements into the 4.0.1 release and 
> > have a quicker release.
> > As of now we are just putting the label "hive-4.0.1-must" on the tickets 
> > and we plan to make sure those get c-picked to the release line. AFAIK we 
> > haven't started committing to any branch yet, was waiting if anyone feels 
> > differently, so we can hold back if you have concerns or take a different 
> > approach as well.
> >
> > From CI you mean to say the daily builds? else if you create a PR targeting 
> > to branch-4.0, it will run the entire test suite I believe? In the meantime 
> > I will update the instructions regarding the target branch & the label if 
> > anyone wants that a particular ticket to be part of the 4.0.1 release.
> >
> > -Ayush
> >
> > On Wed, 17 Apr 2024 at 12:42, Stamatis Zampetakis <zabe...@gmail.com> wrote:
> >>
> >> Thanks for starting the discussion Ayush.
> >>
> >> Having frequent releases is definitely needed so we should keep the
> >> momentum going.
> >>
> >> I had the impression from other threads that the next Hive release
> >> would be 4.1.0 and that it would be cut from master. I would like to
> >> understand how 4.0.1 is different and if it is, what is the
> >> contribution pattern that contributors and committers should follow?
> >> If the idea is to maintain and commit in two (or more) branches the
> >> steps should be documented and CI should be running on those branches.
> >>
> >> Best,
> >> Stamatis
> >>
> >> On Wed, Apr 10, 2024 at 1:18 PM Denys Kuzmenko <dkuzme...@apache.org> 
> >> wrote:
> >> >
> >> > We might need it sooner as identified some critical issues in the recent 
> >> > code:
> >> > 1. HIVE-28166: Truncate on Iceberg table disregards the branch name and 
> >> > operates on a main;
> >> > 2. HIVE-28190: Materialized view rebuild lock heart-beating is broken;
> 

Reply via email to