docs: auto release maven artifacts

[tisonkun]

The proposed process is -

1. PMC votes on an RC version, validating that any binaries are reproducible.
2. After the vote passes, the RM triggers CI to build the 'non-RC' binaries (likely simply by tagging the version), publishing them to a 'staging' environment.
3. The RM is responsible for rebuilding and checking those non-RC binaries locally before promoting/uploading them to whatever distribution channels we use. Other committers can check this work.

But we can staging the artifacts before voting since it's not released. And verify on the artifacts and "Close" & "Release" once vote passed; "Drop" once vote failed.

[tisonkun]

Refer to the tickets that we can/should follow later - https://issues.apache.org/jira/browse/INFRA-23996

Policy changes - https://issues.apache.org/jira/browse/LEGAL-647

[markt-asf]

The review checklist needs to include checking that the release is repeatable.

If the release fails and you tag a new version, why do you need to use rcN version numbers at all?

If you want to use multiple release candidates then the process would be something like:

• set version to X.Y.Z
• tag X.Y.Z-RCN in GitHub
• let CI do its thing
• upload the RC to the various ASF locations (dist, Maven staging)
• VOTE
• if vote fails, repeat from step 1 with RCN => RC(N+1)
• if vote passes, publish releases
• copy final X.Y.Z-RC? tag to X.Y.Z

[tisonkun]

@markt-asf Thanks for your review!

I'll prepare a new version based on the RC flavor.

BTW, is the "if the release fails, then tag a new version" strategy possible following the ASF policy? I'm scheduling a quick sync with other RMs and we may need more info to make a decision from the project side.

[markt-asf]

There are two possible approaches:

• X.Y.Z-RC1, X.Y.Z-RC2, etc and then once an RC passes that tag gets copied to X.Y.Z
• X.Y.Z, X.Y.Z+1, X.Y.Z+2 etc and you only release the versions where the vote passed

Different projects use different approaches. Tomcat uses the second approach. Commons uses the first. In either approach it is the files that are voted on that are released. In the first approach, some renaming of voted on artifacts from X.Y.Z-RCn to X.Y.Z may be required (and is allowed since it doesn't break hashes or signatures).

[tisonkun]

@markt-asf I update the description that we first tag with "-rc" suffix and later promote to a formal tag. All automation will determinate tags pattern and do the correct action.

For Maven central - always staging; close and release on passed; drop on failed.

Other platform is out of ASF platform and we will work out a proper model.

[Xuanwo]

Other LGTM.

[markt-asf]

If I read this correctly the plan is tag X.Y.X as X.Y.Z-rc1, CI builds X.Y.Z, PMC votes on it (including confirming that they can build a bit-for-bit identical result - i.e. the hashes are the same), if the vote passes add a X.Y.Z tag alongside the X.Y.Z-rc1 tag and release. If the vote fails, fix the issues, update version to X.Y.Z+1 and start again. On that basis looks good to me. My only question would be to what extent have you validated that the builds are repeatable?

[tisonkun]

repeatable

@markt-asf It mainly follows Maven Reproducible Builds Guide.

The pom.xml of opendal-java inherits apache's parent pom, which has a property:

<project.build.outputTimestamp>2022-12-11T19:18:10Z</project.build.outputTimestamp>

... and then one can download the staging artifacts, pointing the Maven local repository and check Reproducible report.

[tisonkun]

I've created the INFRA ticket - https://issues.apache.org/jira/browse/INFRA-24880

@markt-asf may you leave a comment there also XD.

[tisonkun]

Pending for merging...

@Xuanwo Please give a review and be aware of that we should tag a -rcN Git tag now for releases. Perhaps we should send an email on the dev mailing list.

[Xuanwo]

Perhaps we should send an email on the dev mailing list.

Yes, and we need to update our release workflow.

[Xuanwo]

Thanks!