I believe it should be 1.4.0. We only did a x.x.1 kind of release once,
when we couldn't release 1.1.0 [1] in the Hadoop 3.3.1 RC1 due to some
issues. Instead, we issued 1.1.1 [2], which was ultimately used in 3.3.1.
However, I can't exactly recall what was the issue which led to 1.1.1, but
I think
On Wed, 5 Mar 2025 at 20:20, PJ Fanning wrote:
> Due to the jar name change for protobuf that is merged but unreleased,
> I think that 1.4.0 is better.
> https://github.com/apache/hadoop-thirdparty/pull/38
OK
>
>
> Is there a reason to not use the pre-existing Avro PR which seems to
> have the
Due to the jar name change for protobuf that is merged but unreleased,
I think that 1.4.0 is better.
https://github.com/apache/hadoop-thirdparty/pull/38
Is there a reason to not use the pre-existing Avro PR which seems to
have the same changes?
https://github.com/apache/hadoop-thirdparty/pull/40
If the application has multiple versions of hadoop as dependency why only
thirdparty jar will conflict? Will the other hadoop jars not conflict?
Well appending the version in the package name won’t be a good idea, for every
thirdparty release we need to change the imports in the hadoop project, a
it's the concept borrowed from HBase. (there's a hbase-thirdparty and it
works quite well there )
it was meant to prevent class name clashes with downstream applications if
they use the same dependency but incompatible versions. (e.g. guava 11 vs
guava 27)
Your scenario could happen if the applic
