Release for 3.1.3 is underway. Initial set of targetted backports are complete. I will follow the remaining steps to have a build soon.
Would be nice to release at a regular cadence. On Tue, Feb 22, 2022 at 6:18 AM Peter Vary <pv...@cloudera.com.invalid> wrote: > 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 > >>>>>> > >>>>> > >>>> > >>> > >> > >
