I would vote for 4.0.0-alpha-1 or similar for all of the components. When we have more stable releases I would keep the 4.x.x schema, since everyone is familiar with it, and I do not see a really good reason to change it.
Thanks, Peter > On 2022. Feb 10., at 3:34, Szehon Ho <szehon.apa...@gmail.com> wrote: > > +1 that would be awesome to see Hive master released after so long. > > Either 4.0 or 4.0.0-alpha-1 makes sense to me, not sure how we would pick > any 3.x or calendar date (which could tend to slip and be more confusing?). > > Thanks in any case to get the ball rolling. > Szehon > > On Wed, Feb 9, 2022 at 4:55 AM Zoltan Haindrich <k...@rxd.hu> wrote: > >> Hey, >> >> Thank you guys for chiming in; versioning is for sure something we should >> get to some common ground. >> Its a triple problem right now; I think we have the following things: >> * storage-api >> ** we have "2.7.3-SNAPSHOT" in the repo >> *** >> https://github.com/apache/hive/blob/0d1cffffc7c5005fe47759298fb35a1c67edc93f/storage-api/pom.xml#L27 >> ** meanwhile we already have 2.8.1 released to maven central >> *** https://mvnrepository.com/artifact/org.apache.hive/hive-storage-api >> * standalone-metastore >> ** 4.0.0-SNAPSHOT in the repo >> ** last release is 3.1.2 >> * hive >> ** 4.0.0-SNAPSHOT in the repo >> ** last release is 3.1.2 >> >> Regarding the actual version number I'm not entirely sure where we should >> start the numbering - that's why I was referring to it as Hive-X in my >> first letter. >> >> I think the key point here would be to start shipping releases regularily >> and not the actual version number we will use - I'll kinda open to any >> versioning scheme which >> reflects that this is a newer release than 3.1.2. >> >> I could imagine the following ones: >> (A) start with something less expected; but keep 3 in the prefix to >> reflect that this is not yet 4.0 >> I can imagine the following numbers: >> 3.900.0, 3.901.0, ... >> 3.9.0, 3.9.1, ... >> (B) start 4.0.0 >> 4.0.0, 4.1.0, ... >> (C) jump to some calendar based version number like 2022.2.9 >> trunk based development has pros and cons...making a move like this >> irreversibly pledges trunk based development; and makes release branches >> hard to introduce >> (X) somewhat orthogonal is to (also) use some suffixes >> 4.0.0-alpha1, 4.0.0-alpha2, 4.0.0-beta1 >> this is probably the most tempting to use - but this versioning >> schema with a non-changing MINOR and PATCH number will >> also suggest that the actual software is fully compatible - and only >> bugs are being fixed - which will not be true... >> >> I really like the idea to suffix these releases with alpha or beta - which >> will communicate our level commitment that these are not 100% production >> ready artifacts. >> >> I think we could fix HIVE-25665; and probably experiment with 4.0.0-alpha1 >> for start... >> >>> This also means there should *not* be a branch-4 after releasing Hive >> 4.0 >>> and let that diverge (and becomes the next, super-ignored branch-3), >> correct; no need to keep a branch we don't maintain...but in any case I >> think we can postpone this decision until there will be something to >> release... :) >> >> cheers, >> Zoltan >> >> >> >> On 2/9/22 10:23 AM, László Bodor wrote: >>> Hi All! >>> >>> A purely technical question: what will the SNAPSHOT version become after >>> releasing Hive 4.0.0? I think this is important, as it defines and >> reflects >>> the future release plans. >>> >>> Currently, it's 4.0.0-SNAPSHOT, I guess it's since Hive 3.0 + branch-3. >>> Hive is an evolving and super-active project: if we want to make regular >>> releases, we should simply release Hive 4.0 and bump pom to >> 4.1.0-SNAPSHOT, >>> which clearly says that we can release Hive 4.1 anytime we want, without >>> being frustrated about "whether we included enough cool stuff to release >>> 5.0". >>> >>> This also means there should *not* be a branch-4 after releasing Hive 4.0 >>> and let that diverge (and becomes the next, super-ignored branch-3), only >>> when we end up bringing a minor backward-incompatible thing that needs a >>> 4.0.x, and when it happens, we'll create *branch-4.0 *on demand. For me, >> a >>> branch called *branch-4.0* doesn't imply either I can expect cool >> releases >>> in the future from there or the branch is maintained and tries to be in >>> sync with the *master*. >>> >>> Regards, >>> Laszlo Bodor >>> >>> Alessandro Solimando <alessandro.solima...@gmail.com> ezt írta (időpont: >>> 2022. febr. 8., K, 16:42): >>> >>>> Hello everyone, >>>> thank you for starting this discussion. >>>> >>>> I agree that releasing the master branch regularly and sufficiently >> often >>>> is welcome and vital for the health of the community. >>>> >>>> It would be great to hear from others too, especially PMC members and >>>> committers, but even simple contributors/followers as myself. >>>> >>>> Best regards, >>>> Alessandro >>>> >>>> On Wed, 2 Feb 2022 at 12:22, Stamatis Zampetakis <zabe...@gmail.com> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> Thanks for starting the discussion Zoltan. >>>>> >>>>> I strongly believe that it is important to have regular and often >>>> releases >>>>> otherwise people will create and maintain separate Hive forks. >>>>> The latter is not good for the project and the community may lose >>>> valuable >>>>> members because of it. >>>>> >>>>> Going forward I fully agree that there is no point bringing up strong >>>>> blockers for the next release. For sure there are many backward >>>>> incompatible changes and possibly unstable features but unless we get a >>>>> release out it will be difficult to determine what is broken and what >>>> needs >>>>> to be fixed. >>>>> >>>>> Due to the big number of changes that are going to appear in the next >>>>> version I would suggest using the terms Hive X-alpha, Hive X-beta for >> the >>>>> first few releases. This will make it clear to the end users that they >>>> need >>>>> to be careful when upgrading from an older version and it will give us >> a >>>>> bit more time and freedom to treat issues that the users will likely >>>>> discover. >>>>> >>>>> The only real blocker that we may want to treat is HIVE-25665 [1] but >> we >>>>> can continue the discussion under that ticket and re-evaluate if >>>> necessary, >>>>> >>>>> Best, >>>>> Stamatis >>>>> >>>>> [1] https://issues.apache.org/jira/browse/HIVE-25665 >>>>> >>>>> >>>>> On Tue, Feb 1, 2022 at 5:03 PM Zoltan Haindrich <k...@rxd.hu> wrote: >>>>> >>>>>> Hey All, >>>>>> >>>>>> We didn't made a release for a long time now; (3.1.2 was released on >> 26 >>>>>> August 2019) - and I think because we didn't made that many branch-3 >>>>>> releases; not too many fixes >>>>>> were ported there - which made that release branch kinda erode away. >>>>>> >>>>>> We have a lot of new features/changes in the current master. >>>>>> I think instead of aiming for big feature-packed releases we should >> aim >>>>>> for making a regular release every few months - we should make regular >>>>>> releases which people could >>>>>> install and use. >>>>>> After all releasing Hive after more than 2 years would be big step >>>>> forward >>>>>> in itself alone - we have so many improvements that I can't even >>>> count... >>>>>> >>>>>> But I may know not every aspects of the project / states of some >>>> internal >>>>>> features - so I would like to ask you: >>>>>> What would be the bare minimum requirements before we could release >> the >>>>>> current master as Hive X? >>>>>> >>>>>> There are many nice-to-have-s like: >>>>>> * hadoop upgrade >>>>>> * jdk11 >>>>>> * remove HoS or MR >>>>>> * ? >>>>>> but I don't think these are blockers...we can make any of these in the >>>>>> next release if we start making them... >>>>>> >>>>>> cheers, >>>>>> Zoltan >>>>>> >>>>> >>>> >>> >>
