Hey Laszlo, Thanks a lot for pushing this forward. I really love the diff in the PR that shows 120K lines of code less than before :)
Apache software is not very different from enterprise software so the same applies to releases as well. Cutting a new release/branch would mean that we have to support and maintain it as we do for other releases lines. It also means that it will cost us infra resources since we will have to enable some kind of CI if we want to accept PRs and keep things reasonably stable. If there is a team of people that are willing to drive this effort then nothing prevents us from having such a release. I would suggest to find at least 2 PMC members that are willing to drive this effort (prepare releases, drive CVE discussions, etc.) and a few committers for reviewing and merging PRs. If there are enough volunteers then I am fine with moving forward with such a plan. Personally, I would prefer to see this land in the main master branch/release rather than dividing our efforts into maintaining separate branches. Upgrading to the latest release of a software is a challenge itself so if we have multiple "latest" releases then the challenge becomes even greater and may interfere a bit with the adoption. Best, Stamatis On Fri, Aug 18, 2023 at 12:09 PM Laszlo Vegh <lv...@cloudera.com.invalid> wrote: > > > Laszlo Vegh > lv...@cloudera.com > > > Hi all, > > I have a PR (https://github.com/apache/hive/pull/4060) which replaces the > current custom HMS schema evolution tool with Liquibase. The PR contains two > documents about the possible benefits, and about how to contribute new schema > changes in the new ecosystem. > > Unfortunately it’s too big, and also contains key infrasrtucture related > changes, so it’s not the best idea to merge it directly to master. I’m > thinking about creating a separate branch, or dedicated release. It would > based on master, and would be in sync with it, but it would also contain the > Liquibase introduction PR. With this approach it would be easier to test it, > play with it, and merge back to master only when it is considered as stable. > > I’m not sure what is the “Apache way” of doing this, is there any > recommendation, or approach about creating such versions/releases? > > Best regards, > Laszlo Vegh
