Some progress here.
With other developers help(especially Nick, Andrew and Guanghao), I've
successfully made the release scripts able to publish binaries and
maven artifacts for hadoop3, in a dry run mode,
https://github.com/apache/hbase/pull/4856
I've put up a discussion thread, for quickly releasing 2.5.2 for the
2.5 release line, with hadoop3 binaries. Please shout if you have any
ideas.
Thanks.
张铎(Duo Zhang) 于2022年10月24日周一 12:27写道：
>
> HBASE-27434 has been landed to branch-2.5+. Branch-2.4 does not have a
> flatten plugin so do not apply HBASE-27434 to it.
>
> Filed HBASE-27442 for changing the way of bumping versions in release scripts.
>
> After this change, let's finally go back to HBASE-27359 to make the
> release scripts publish different artifacts for hadoop2 and hadoop3.
>
> Thanks.
>
> Andrew Purtell 于2022年10月19日周三 23:36写道：
> >
> > Suggestions:
> >
> > - For HBase 2.x releases, we should continue to publish default builds,
> > those without any -hadoop3- or -widgetfoo- modifiers, against Hadoop 2.
> >
> > - For HBase 3, it makes sense to move the default to Hadoop 3, no other
> > build variants needed there. This is the kind of thing a major version
> > increment allows us to do per our dependency compatibility guidelines.
> >
> > - While eventually it may be necessary to differentiate between minor
> > release lines of Hadoop it would be simpler to pick one Hadoop 3 version,
> > like 3.3.4, and build and publish a -hadoop3- artifact for each current
> > releasing 2.x code line: 2.4.15-hadoop3, 2.5.2-hadoop3, 2.6.0-hadoop3.
> >
> > - The process of building releases is automated by create-release, which
> > all RMs use now. create-release automates the process of building and
> > signing tarballs and publishing to Nexus. There should be no significant
> > new burden on the RM, beyond an increase in time for create-release
> > execution, to parameterize it and iterate over one or more variant builds.
> > That is a long way of suggesting we do publish variant tarballs too, they
> > are almost "for free" if we've gone to the trouble to build for publishing
> > to Nexus.
> >
> >
> > On Wed, Oct 19, 2022 at 12:52 AM 张铎(Duo Zhang)
> > wrote:
> >
> > > After some investigating, I think using the $revision placeholder can
> > > solve the problem here, i.e, using different command line to publish
> > > different artifacts for hadoop2 and hadoop3, with the same souce code.
> > > You can see the comment on HBASE-27359 for more details.
> > >
> > > Next I will open an issue to land the $revision change. And here, I
> > > think first we need to discuss how many new artifacts we want to
> > > publish. For example, for 2.6.0, we only want to publish a
> > > 2.6.0-hadoop3, with the default hadoop3 version? Or we publish
> > > 2.6.0-hadoop3.2, 2.6.0-hadoop3.3 for different hadoop minor release
> > > lines? And do we want to publish different tarballs for hadoop2 and
> > > hadoop3?
> > >
> > > Thanks.
> > >
> > > Andrew Purtell 于2022年8月31日周三 00:19写道：
> > > >
> > > > I also don't think we should change the defaults in branch-2 until
> > > Hadoop 2
> > > > is EOLed.
> > > >
> > > > On Mon, Aug 29, 2022 at 10:22 AM Sean Busbey wrote:
> > > >
> > > > > I think changing the default hadoop profile for builds in branch-2
> > > would
> > > > > unnecessarily complicate our compatibility messaging so long as Hadoop
> > > 2
> > > > > hasn't gone EOL.
> > > > >
> > > > > On Mon, Aug 29, 2022 at 5:30 AM Nick Dimiduk
> > > wrote:
> > > > >
> > > > > > Should we also make hadoop3 the default active profile for branch-2
> > > going
> > > > > > forward?
> > > > > >
> > > > > > On Fri, Aug 26, 2022 at 5:25 PM Andrew Purtell <
> > > andrew.purt...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > The security posture of Hadoop 2 in general is a problem, because
> > > > > > > maintenance on that branch is spotty, that is just how it goes. We
> > > had
> > > > > > the
> > > > > > > same situation with our now EOL branch-1. I know Hadoop released
> > > 2.10.2
> > > > > > to
> > > > > > > address some CVE worthy problems but it is unclear if 2.10.2
> > > addresses
> > > > > > all
> > > > > > > known issues, unlike 3.3.4. Also as you know Hadoop 2 has
> > > unpatchable
> > > > > > > dependencies on org.codehaus versions of Jackson and Jetty, which
> > > > > > > themselves have high scoring CVEs that will never be fixed because
> > > they
> > > > > > are
> > > > > > > EOL, and other similar issues. Hadoop 3 doesn’t completely solve
> > > such
> > > > > > > problems but is the only realistic place we can hope they can be
> > > > > > addressed
> > > > > > > as required. For organizations that implement or require a top to
> > > > > bottom
> > > > > > > security audit of their software bill of materials, it seems
> > > possible
> > > > > to
> > > > > > > avoid user pain by providing supported convenience artifacts *and*
> > > > > > > libraries built against Hadoop 3 APIs in the Apache repository
> > > > > >
