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 opted to do a smaller release from branch-4.0 (4.0.1) which so far has accumulated 28 commits. The original idea was this to be a quick release but as it turns out things keep accumulating so the argument of having few and small fixes that are easy to test fades away. I will resurface the suggestion that I brought up in the past about cutting releases only from the master branch and I would like to propose the following high-level model. * Commit and release always from master. * Release regularly (every ~3months). * Follow semantic versioning (major.minor.patch); by default we bump minor digit. * Finalize version digit bump based on the content when preparing the release candidate. * Strive to minimize major version bumps by guarding risky/breaking changes using configuration flags (we are already doing this more or less). * Stop maintenance releases; every new release subsumes the previous one. The above are not set in stone and we can iterate on it till we have something that makes everyone happy. I am proposing this model mainly for two reasons: * increase release cadence; * reduce maintenance burden for the community. Looking forward to your thoughts. Best, Stamatis On 2024/04/18 12:33:48 Denys Kuzmenko wrote: > 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 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 don't see a big benefit to release from side > > branches. > > > > Again the motivation for releasing early and often from master is that > > it has less maintenance overhead for the community and the end-users > > can benefit from all improvements as soon as possible. Certainly if we > > introduce breaking changes and big risky features this approach cannot > > work. > > > > Anyways, I am glad that we are having this discussion and it's also > > very positive that we are talking about a new release in less than a > > month since 4.0.0 came out. No matter if it is 4.0.1 or 4.1.0 I am > > fully onboard and happy to help as much as I can :) > > > > Best, > > Stamatis > > > > On Thu, Apr 18, 2024 at 11:53 AM Denys Kuzmenko <dkuzme...@apache.org> > > wrote: > > > > > > 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; > > > > > > >
