In general, Source Release is the primary focus of Apache and a necessary element of the release; Binary Release is optional, and Dubbo can choose whether to release binary packages to the Apache repository or publish to the Maven Central Repository.
Please refer to the following links for more information about the ASF release guidelines:
Create a new branch from the trunk as a release branch. For example, to release version ${release_version}
, create a new branch ${release_version}-release
from the development branch. All modifications and tagging related to ${release_version}
Release Candidates will then occur in the ${release_version}-release
branch, merging back to the trunk after the final release is complete.
In the corresponding GitHub repository, tag the ${release_version}-release
branch, fill out the Release Note, and publish it as a Pre Release status. (The release status must not be changed to formal release status until the voting process is officially passed.)
Note: After tagging, no commits can be made to this branch. The last commit in the branch must be the tagged commit and the commit in the vote.
Push the binary package to the hosting platform using a build tool, such as releasing the Java SDK to the Maven repository in Staging.
Note: If the hosting platform does not support pre-release functionality, it must be released only after the vote passes.
Package the source code in zip format, sign it with your personal gpg key to get the asc file, and generate the sha512 file using the shasum tool.
Example: For releasing version 3.0.10
of the Java SDK, build apache-dubbo-3.0.10-src.zip
, apache-dubbo-3.0.10-src.zip.asc
, and apache-dubbo-3.0.10-src.zip.sha512
.
Push the Source Release files to the https://dist.apache.org/repos/dist/dev/dubbo/
repository, storing the files in the https://dist.apache.org/repos/dist/dev/dubbo/${component_name}/${release_version}/
directory. (Committer permission is required to push.)
Send the voting email using the Apache email. The subject of the voting email is: [VOTE] Release ${component_name} ${release_version} RC1
, and the email content must include the following:
The above Source Release, Tag, Hash, and Release Note must correspond completely.
Example: For releasing version 3.0.10
of the Java SDK, the email sent would be as follows:
For a detailed checklist, please refer to the official checklist.
After waiting at least 72 hours and receiving at least 3 +1 approve votes from PMC, an email can be sent to announce the voting results. The subject of the voting results email is: [RESULT] [VOTE] Release ${component_name} ${release_version} RC1
, and the email content must include the voting PMC information and the voting thread.
(You can find it through https://lists.apache.org/list.html?dev@dubbo.apache.org.)
Example: For releasing version 2.7.16
of the Java SDK, the email sent would be as follows:
Officially update the tag made in step 2 to the formal release status on GitHub.
Merge ${release_version}-release
back into the development trunk and update the latest snapshot version number. (${release_version}-release
can be deleted.)
Move the Source Release files stored in the https://dist.apache.org/repos/dist/dev/dubbo/
repository to https://dist.apache.org/repos/dist/release/dubbo/
repository. (Only PMC has permission to do this.)
At the same time, delete the previous Source Release files. (They will automatically be stored in the Archive repository.)
Update the pre-released binary package from step 3 to be in formal release status.
Update the latest Source Release and other information in the corresponding file of dubbo-website
, including at least the download method for the Source Release and the reference method for the binary package (if any), while updating historical release links to the archive domain.
The subject of the voting result email should be: [Announce] Release ${component_name} ${release_version} released
.
Note: It is best to wait until the binary package goes live in formal status before sending this email.