Just a few known issues in master:
https://issues.apache.org/jira/issues/?jql=labels%20%3D%20hive-4.1.0-must%20and%20resolution%20%3D%20Unresolved
To get a better view of things, we need to execute TPC-DS workload against
branch-4.0.1 and master.
Butao Zhang
Replied Message
| From | Zhihua Deng |
| Date | 8/1/2024 11:47 |
| To | |
| Subject | Re: [DISCUS] Plan the next Hive release |
Hi All,
Hive 4.0.1 Overview:
Now there are six Hive issues that tagged with hive-4.0.1-must left un-merged
to branch-4.0, most of them are resolved o
Hi All,
Hive 4.0.1 Overview:
Now there are six Hive issues that tagged with hive-4.0.1-must left un-merged
to branch-4.0, most of them are resolved on the master. Regarding to TEZ-4557,
a workaround in Hive is to add the missing jars to the hive.aux.jars.path,
which is acceptable, from my pers
Hi Stamatis,
`It's been already 4 months since the release of Hive 4.0.0`. That's true,
Zhihua can give a more detailed view of things, however, the main reason is
that it took a while to resolve the identified bugs.
ATM the only blocking item is TEZ-4557, which might not be available until
Se
Hi all,
It's been already 4 months since the release of Hive 4.0.0 and master is
already 163 ahead. Based on the initial discussion we would like to cut a
release from master every 3-4 months and it seems that we are already behind
schedule.
Instead of focusing on releasing from master we opte
The idea is to cherry-pick individual bug fixes/improvements that could be
easily tested to avoid a complete release test cycle (TPC-DS performance suite,
multi-db tests, etc)
On 2024/04/18 11:22:09 Stamatis Zampetakis wrote:
> There are also many projects that never create minor version release
There are also many projects that never create minor version releases;
it's up to each project to decide what fits best on each occasion.
I am not against minor releases nor suggest that this should be the
way to go for every release from now onwards. I am just saying that at
this point in time I
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 m
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
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-pic
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 a
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;
+1. Thank you Ayush, for pushing things forward!
I would like to volunteer for the 4.0.1 release.
Thanks,
Zhihua
On 2024/04/09 22:30:55 Ayush Saxena wrote:
> Hi All,
> As we all know Hive-4.0 is released. I think we should try to maintain a
> regular cadence for the 4.x release line.
> So, I pr
Hi All,
As we all know Hive-4.0 is released. I think we should try to maintain a
regular cadence for the 4.x release line.
So, I propose having a 4.0.1 release in the next 3 months or so, with some
critical bug fixes and improvements on top of our last 4.0.0 release.
We would need someone to volun
14 matches
Mail list logo
