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