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
