This is an automated email from the ASF dual-hosted git repository.
jark pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/fluss.git
The following commit(s) were added to refs/heads/main by this push:
new f116202c9 [website] Add How to Release and Verify for fluss-shaded
releases (#1500)
f116202c9 is described below
commit f116202c9bc49ed89f98034af159cfce4a85d8e7
Author: Jark Wu <[email protected]>
AuthorDate: Fri Aug 8 00:24:22 2025 +0800
[website] Add How to Release and Verify for fluss-shaded releases (#1500)
---
website/community/assets/nexus-staging.png | Bin 0 -> 414926 bytes
website/community/assets/release-guide.png | Bin 0 -> 363329 bytes
website/community/how-to-release.md | 9 -
website/community/how-to-release/_category_.json | 4 +
.../creating-a-fluss-shaded-release.md | 469 +++++++++++++++++++++
.../how-to-release/release-manager-preparation.md | 208 +++++++++
.../verifying-a-fluss-shaded-release.md | 98 +++++
7 files changed, 779 insertions(+), 9 deletions(-)
diff --git a/website/community/assets/nexus-staging.png
b/website/community/assets/nexus-staging.png
new file mode 100644
index 000000000..f6e9bed9f
Binary files /dev/null and b/website/community/assets/nexus-staging.png differ
diff --git a/website/community/assets/release-guide.png
b/website/community/assets/release-guide.png
new file mode 100644
index 000000000..bf7602dde
Binary files /dev/null and b/website/community/assets/release-guide.png differ
diff --git a/website/community/how-to-release.md
b/website/community/how-to-release.md
deleted file mode 100644
index 2e4032a92..000000000
--- a/website/community/how-to-release.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: How to Release
-sidebar_position: 3
----
-
-# How to Release
-
-TODO
-
diff --git a/website/community/how-to-release/_category_.json
b/website/community/how-to-release/_category_.json
new file mode 100644
index 000000000..b2d9de979
--- /dev/null
+++ b/website/community/how-to-release/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "How to Release",
+ "position": 3
+}
diff --git
a/website/community/how-to-release/creating-a-fluss-shaded-release.md
b/website/community/how-to-release/creating-a-fluss-shaded-release.md
new file mode 100644
index 000000000..0ca0b6892
--- /dev/null
+++ b/website/community/how-to-release/creating-a-fluss-shaded-release.md
@@ -0,0 +1,469 @@
+---
+title: Creating a Fluss Shaded Release
+sidebar_position: 2
+---
+
+# Creating a Fluss Shaded Release
+
+:::note
+This is based on the release guide of the [Apache Flink
project](https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release).
+:::
+
+The Apache Fluss (Incubating) project periodically declares and publishes
releases. A release is one or more packages of the project artifact(s) that are
approved for general public distribution and use. The Fluss community treats
releases with great importance. They are a public face of the project and most
users interact with the project only through the releases. Releases are signed
off by the entire Fluss community in a public vote.
+
+Each release is executed by a Release Manager, who is selected/proposed by the
Fluss PPMC members. This document describes the process that the Release
Manager follows to perform a release. Any changes to this process should be
discussed and adopted on the dev@ mailing list.
+
+Please remember that publishing software has legal consequences. This guide
complements the foundation-wide [Product Release
Policy](https://www.apache.org/legal/release-policy.html) and [Release
Distribution Policy](https://infra.apache.org/release-distribution.html).
+
+## Overview
+
+
+
+The release process consists of several steps:
+
+1. [Decide to release](#decide-to-release)
+2. [Prepare for the release](#prepare-for-the-release)
+3. [Build a release candidate](#build-a-release-candidate)
+4. [Vote on the release candidate](#vote-on-the-release-candidate)
+5. [If necessary, fix any issues and go back to step 3](#fix-any-issues)
+6. [Finalize the release](#finalize-the-release)
+7. [Promote the release](#promote-the-release)
+
+## Decide to release
+
+Deciding to release and selecting a Release Manager is the first step of the
release process. This is a consensus-based decision of the entire community.
+
+Anybody can propose a release on the dev@ mailing list, giving a solid
argument and nominating a committer as the Release Manager (including
themselves). There’s no formal process, no vote requirements, and no timing
requirements. Any objections should be resolved by consensus before starting
the release.
+
+In general, the community prefers to have a rotating set of 3-5 Release
Managers. Keeping a small core set of managers allows enough people to build
expertise in this area and improve processes over time, without Release
Managers needing to re-learn the processes for each release. That said, if you
are a committer interested in serving the community in this way, please reach
out to the community on the dev@ mailing list.
+
+**Checklist to proceed to the next step**
+- Community agrees to release
+- Community selects a Release Manager
+
+## Prepare for the release
+
+#### 0. One-time Release Manager setup
+
+Before your first release, you should perform one-time configuration steps.
This will set up your security keys for signing the release and access to
various release repositories. Please check the **[Release Manager
Preparation](release-manager-preparation.md)** guide for details.
+
+To prepare for each release, you should audit the project status in the GitHub
issue tracker, and do necessary bookkeeping. Finally, you should create a
release branch from which individual release candidates will be built.
+
+#### 1. Setup environment variables
+
+Set up a few environment variables to simplify commands that follow. (We use
bash Unix syntax in this guide.)
+
+```bash
+RELEASE_VERSION="1.0-incubating"
+RELEASE_VERSION_SHORT="1.0"
+NEXT_VERSION="2.0-incubating"
+```
+
+#### 2. Verify Java and Maven Version
+
+All of the following steps require to use **Maven 3.8.6** and **Java 8**.
Modify your `PATH` environment variable accordingly if needed.
+
+#### 3. Clone fluss-shaded into a fresh workspace
+
+Clone the Fluss repository into a fresh workspace. This is important to ensure
that you are working with a clean state.
+
+```bash
+git clone [email protected]:apache/fluss-shaded.git
+```
+
+#### 4. Create a release branch
+
+Create a release branch from the `main` branch. This branch will be used to
build the release candidate.
+
+```bash
+$ cd tools
+tools $ git checkout main
+tools $ git checkout -b release-${RELEASE_VERSION_SHORT}
+tools $ git push origin release-${RELEASE_VERSION_SHORT}
+```
+
+#### 5. Bump version for the main branch
+
+After creating the release branch, you should bump the version of the main
branch to the next version. This is important to ensure that the next
development cycle starts with the correct version.
+
+```bash
+tools $ git checkout main
+tools $ OLD_VERSION=$RELEASE_VERSION NEW_VERSION=$NEXT_VERSION
releasing/update_branch_version.sh
+tools $ git push origin main
+```
+
+The newly created branch and updated master branch need to be pushed to the
official repository.
+
+**Checklist to proceed to the next step**
+
+- Release Manager’s GPG key is published to
[dist.apache.org](https://dist.apache.org/repos/dist/release/incubator/fluss/KEYS)
+- Release Manager’s GPG key is configured in git configuration
+- Release Manager's GPG key is configured as the default gpg key.
+- Release Manager has `org.apache.fluss` listed under `Staging Profiles` in
Nexus
+- Release Manager’s Nexus User Token is configured in `settings.xml`
+- There are no release blocking GitHub issues
+- Release branch (`release-x.0`) has been created and pushed
+- Main branch has been updated to the next version and pushed
+
+## Build a release candidate
+
+The core of the release process is the build-vote-fix cycle. Each cycle
produces one release candidate. The Release Manager repeats this cycle until
the community approves one release candidate, which is then finalized.
+
+### 1. Create RC branch and tag
+
+Set up a few environment variables to simplify Maven commands that follow.
This identifies the release candidate being built. Start with `RC_NUM` equal to
1 and increment it for each candidate.
+
+```bash
+RC_NUM="1"
+TAG="v${RELEASE_VERSION}-rc${RC_NUM}"
+```
+
+Now, checkout from the release branch, and create a release candidate local
branch:
+
+```bash
+$ git checkout release-${RELEASE_VERSION_SHORT}
+$ cd tools
+tools $ RELEASE_CANDIDATE=$RC_NUM RELEASE_VERSION=$RELEASE_VERSION
releasing/create_release_branch.sh
+```
+
+Tag the release commit:
+
+```bash
+git tag -s ${TAG} -m "${TAG}"
+```
+
+### 2. Stage source release files
+
+First, we build the source release:
+
+```bash
+tools $ RELEASE_VERSION=$RELEASE_VERSION releasing/create_source_release.sh
+```
+
+This command creates a source tarball and signs it under `tools/release`
directory.
+
+Next, copy the source release files to the dev repository of dist.apache.org.
+
+(1) If you have not already, check out the Fluss section of the dev repository
on dist.apache.org via Subversion. In a fresh directory (e.g., `tools/target`):
+
+```bash
+tools $ mkdir target
+tools $ cd target
+tools/target $ svn checkout
https://dist.apache.org/repos/dist/dev/incubator/fluss --depth=immediates
+```
+
+(2) Make a directory for the new release:
+
+```bash
+mkdir fluss/fluss-shaded-${RELEASE_VERSION}-rc${RC_NUM}
+```
+
+(3) Copy fluss-shaded source distributions, hashes, and GPG signature:
+
+```bash
+tools/target $ mv ../release/*
fluss/fluss-shaded-${RELEASE_VERSION}-rc${RC_NUM}
+```
+
+(4) Add and commit all the files.
+
+```bash
+cd fluss
+svn add fluss-shaded-${RELEASE_VERSION}-rc${RC_NUM}
+svn commit -m "Add fluss-shaded-${RELEASE_VERSION}-rc${RC_NUM}"
+```
+
+(5) Verify the files are present:
https://dist.apache.org/repos/dist/dev/incubator/fluss/
+
+
+### 3. Stage maven artifacts
+
+
+Next, we stage the maven artifacts:
+
+```bash
+tools $ releasing/deploy_staging_jars.sh
+```
+
+Review all staged artifacts in the staging
repositories(https://repository.apache.org/#stagingRepositories). They should
contain all relevant parts for each module, including pom.xml, jar, test jar,
source, test source, javadoc, etc. Carefully review any new artifacts.
(fluss-shaded doesn’t deploy test jar, source jar, and javadoc jar, see the
[issue](https://github.com/apache/fluss-shaded/blob/main/README.md#sources) for
more details)
+
+Close the staging repository on Apache Nexus. When prompted for a description,
enter `Apache Fluss (Incubating), version X, release candidate Y`. You can find
the staging repository URL
(`https://repository.apache.org/content/repositories/orgapachefluss-[STAGING_ID]/`)
once the staging repository is closed successfully.
+
+
+
+
+### 4. Push the RC tag
+
+```bash
+git push <remote> refs/tags/{$TAG}
+```
+
+
+**Checklist to proceed to the next step**
+
+- Maven artifacts deployed to the staging repository of
[repository.apache.org](https://repository.apache.org/content/repositories/)
+- Source distribution deployed to the dev repository of
[dist.apache.org](https://dist.apache.org/repos/dist/dev/incubator/fluss/)
+- RC tag pushed to the [official
repository](https://github.com/apache/fluss-shaded/tags)
+
+
+## Vote on the release candidate
+
+Once you have built and individually reviewed the release candidate, please
share it for the community-wide review. Please review foundation-wide [voting
guidelines](https://www.apache.org/foundation/voting.html) for more information.
+
+Fluss is an incubating project, so the release requires a [two-phase
vote](https://incubator.apache.org/cookbook/#two_phase_vote_on_podling_releases),
first by the Fluss community, and then by the Incubator PMC.
+
+### Fluss Community Vote
+
+Start the review-and-vote thread on the dev@ mailing list. Here’s an email
template; please adjust as you see fit.
+
+```
+From: Release Manager
+To: [email protected]
+Subject: [VOTE] Release fluss-shaded 1.0-incubating (RC3)
+
+Hi everyone,
+
+Please review and vote on the release candidate #3 for the fluss-shaded
version 1.0-incubating, as follows:
+[ ] +1, Approve the release
+[ ] -1, Do not approve the release (please provide specific comments)
+
+
+The complete staging area is available for your review, which includes:
+* the official Apache source release and binary convenience releases to be
deployed to dist.apache.org [1], which are signed with the key with fingerprint
FFFFFFFF [2],
+* all artifacts to be deployed to the Maven Central Repository [3],
+* source code tag "release-1.0-incubating-rc3" [4],
+
+The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PPMC affirmative votes.
+
+Thanks,
+Release Manager
+
+[1] link
+[2] https://dist.apache.org/repos/dist/release/incubator/fluss/KEYS
+[3] link
+[4] link
+```
+
+**If there are any issues found in the release candidate**, reply on the vote
thread to cancel the vote. There’s no need to wait 72 hours. Proceed to the
[Fix Issues](#fix-any-issues) step below and address the problem. However, some
issues don’t require cancellation. For example, if an issue is found in the
website pull request, just correct it on the spot and the vote can continue
as-is.
+
+For cancelling a release, the release manager needs to send an email to the
release candidate thread, stating that the release candidate is officially
cancelled. Next, all artifacts created specifically for the RC in the previous
steps need to be removed:
+
+- Delete the staging repository in Nexus
+- Remove the source / binary RC files from dist.apache.org
+- Delete the source code tag in git
+
+**If there are no issues**, reply on the vote thread to close the voting.
Then, tally the votes in a separate email. Here’s an email template; please
adjust as you see fit.
+
+```
+From: Release Manager
+To: [email protected]
+Subject: [RESULT][VOTE] Release fluss-shaded 1.0-incubating (RC3)
+
+I'm happy to announce that we have unanimously approved this release.
+
+There are XXX approving votes, XXX of which are binding:
+* approver 1
+* approver 2
+* approver 3
+* approver 4
+
+There are no disapproving votes.
+
+Thanks everyone!
+
+A new vote is starting in the Apache Incubator general mailing list.
+```
+
+### Incubator PMC Vote
+
+Once the Fluss community has approved the release candidate, the release
manager should start a vote on the [email protected] mailing list to
get the approval from the Incubator PMC. Here’s an email template; please
adjust as you see fit.
+
+```
+From: Release Manager
+To: [email protected]
+Subject: [VOTE] Release Apache Fluss Shaded 1.0-incubating (RC3)
+
+Hi everyone,
+
+The Apache Fluss community has voted and approved the release of
+Apache Fluss Shaded 1.0-incubating (rc3). We now kindly request the IPMC
+members to review and vote for this release.
+
+Apache Fluss (Incubating) - A streaming storage built for real-time analytics
which can serve as the real-time data layer for Lakehouse architectures.
+
+Fluss community vote thread:
+* https://lists.apache.org/thread/<VOTE THREAD>
+
+Vote result thread:
+* https://lists.apache.org/thread/<VOTE RESULT>
+
+The release candidate:
+*
https://dist.apache.org/repos/dist/dev/incubator/fluss/fluss-shaded-1.0-incubating-rc3/
+
+Git tag for the release:
+* https://github.com/apache/fluss-shaded/releases/tag/v1.0-incubating-rc3
+
+Git commit for the release:
+* https://github.com/apache/fluss-shaded/commit/<COMMIT>
+
+Maven staging repository:
+* https://repository.apache.org/content/repositories/orgapachefluss-<ID>/
+
+The artifacts signed with PGP key [FFFFFFFF], corresponding to
+[[email protected]], that can be found in keys file:
+https://downloads.apache.org/incubator/fluss/KEYS
+
+Please download, verify and test.
+
+Please vote in the next 72 hours.
+
+[ ] +1 approve
+[ ] +0 no opinion
+[ ] -1 disapprove with the reason
+
+To learn more about Apache Fluss, please see https://fluss.apache.org/
+
+Checklist for reference:
+
+[ ] Download links are valid.
+[ ] Checksums and signatures.
+[ ] LICENSE/NOTICE files exist
+[ ] No unexpected binary files
+[ ] All source files have ASF headers
+[ ] Can compile from source
+
+Thanks!
+
+Regards,
+Release Manager
+```
+
+Binding votes are the votes from the IPMC members. Similar to the previous
vote, send the result on the Incubator general mailing list:
+
+```
+From: Release Manager
+To: [email protected]
+Subject: [RESULT][VOTE] Release Apache Fluss Shaded 1.0-incubating (RC3)
+
+I'm happy to announce that we have unanimously approved this release.
+
+There are XXX approving votes, XXX of which are binding:
+* approver 1
+* approver 2
+* approver 3
+* approver 4
+
+There are no disapproving votes.
+
+Thanks everyone!
+```
+
+**Checklist to proceed to the finalization step**
+- Community votes to release the proposed candidate, with at least three
approving PPMC votes
+- Incubator votes to release the proposed candidate, with at least three
approving IPMC votes
+
+
+
+## Fix any issues
+
+Any issues identified during the community review and vote should be fixed in
this step.
+
+Code changes should be proposed as standard pull requests to the `main` branch
and reviewed using the normal contributing process. Then, relevant changes
should be **cherry-picked into the release branch**. The cherry-pick commits
should then be proposed as the pull requests against the release branch, again
reviewed and merged using the normal contributing process.
+
+Once all issues have been resolved, you should go back and build a new release
candidate with these changes.
+
+**Checklist to proceed to the next step**
+- Issues identified during vote have been resolved, with fixes committed to
the release branch.
+
+## Finalize the release
+
+Once the release candidate has been reviewed and approved by the community,
the release should be finalized. This involves the final deployment of the
release candidate to the release repositories, merging of the website changes,
etc.
+
+#### Deploy artifacts to Maven Central Repository
+
+Use the [Apache Nexus](https://repository.apache.org/) repository to release
the staged binary artifacts to the Maven Central repository. In the `Staging
Repositories` section, find the relevant release candidate `orgapachefluss-XXX`
entry and click `Release`. Drop all other release candidates that are not being
released.
+
+#### Deploy source and binary releases to dist.apache.org
+
+Copy the source and binary releases from the dev repository to the release
repository at dist.apache.org using Subversion.
+
+```bash
+svn move -m "Release Fluss Shaded ${RELEASE_VERSION}"
https://dist.apache.org/repos/dist/dev/incubator/fluss/fluss-shaded-${RELEASE_VERSION}-rc${RC_NUM}
https://dist.apache.org/repos/dist/release/incubator/fluss/fluss-shaded-${RELEASE_VERSION}
+```
+(Note: Only PPMC members have access to the release repository. If you do not
have access, ask on the mailing list for assistance.)
+
+#### Remove old release candidates from dist.apache.org
+
+Remove the old release candidates from
https://dist.apache.org/repos/dist/dev/incubator/fluss using Subversion.
+
+```bash
+svn checkout https://dist.apache.org/repos/dist/dev/incubator/fluss
--depth=immediates
+cd fluss
+svn remove fluss-shaded-${RELEASE_VERSION}-rc*
+svn commit -m "Remove old release candidates for Apache Fluss Shaded
${RELEASE_VERSION}"
+```
+
+#### Git tag
+
+Create and push a new Git tag for the released version by copying the tag for
the final release candidate, as follows:
+
+```bash
+git tag -s "v${RELEASE_VERSION}" refs/tags/${TAG}^{} -m "Release Fluss Shaded
${RELEASE_VERSION}"
+git push <remote> refs/tags/v${RELEASE_VERSION}
+```
+
+**Checklist to proceed to the next step**
+- Maven artifacts released and indexed in the Maven Central Repository
(usually takes about a day to show up)
+- Source & binary distributions available in the release repository of
https://dist.apache.org/repos/dist/release/incubator/fluss/
+- Dev repository https://dist.apache.org/repos/dist/dev/incubator/fluss/ is
empty
+- Release tagged in the source code repository
+
+## Promote the release
+
+Once the release has been finalized, the last step of the process is to
promote the release within the project and beyond. Please wait for 24h after
finalizing the release in accordance with the [ASF release
policy](https://www.apache.org/legal/release-policy.html#release-announcements).
+
+Announce on the dev@ mailing list that the release has been finished.
+
+Announce on the release on the user@ mailing list, listing major improvements
and contributions.
+
+Announce the release on the [email protected] mailing list.
+
+```
+From: Release Manager
+To: [email protected], [email protected], [email protected]
+Subject: [ANNOUNCE] Apache Fluss Shaded 1.0-incubating released
+
+The Apache Fluss community is very happy to announce the release of Apache
Fluss Shaded 1.0-incubating.
+
+Apache Fluss is a streaming storage built for real-time analytics which can
serve as the real-time data layer for Lakehouse architectures.
+
+The release is available for download at:
+https://downloads.apache.org/incubator/fluss/fluss-shaded-1.0-incubating/
+
+Maven artifacts for Fluss Shaded can be found at:
+
+https://central.sonatype.com/search?q=g%3Aorg.apache.fluss+shade&smo=true
+
+We would like to thank all contributors of the Apache Fluss community who made
this release possible!
+
+Feel free to reach out to the release managers (or respond to this thread)
with feedback on the release process. Our goal is to constantly improve the
release process. Feedback on what could be improved or things that didn't go so
well are appreciated.
+
+Regards,
+Release Manager
+```
+
+#### Recordkeeping
+
+Use [reporter.apache.org](https://reporter.apache.org/addrelease.html?fluss)
to seed the information about the release into future project reports.
+
+(Note: Only PMC members have access report releases. If you do not have
access, ask on the mailing list for assistance.)
+
+***Checklist to declare the process completed***
+- Release announced on the dev@ and user@ mailing list.
+- Release recorded in reporter.apache.org.
+- Completion declared on the dev@ mailing list.
+
+## Improve the process
+
+It is important that we improve the release processes over time. Once you’ve
finished the release, please take a step back and look what areas of this
process and be improved. Perhaps some part of the process can be simplified.
Perhaps parts of this guide can be clarified.
+
+If we have specific ideas, please start a discussion on the dev@ mailing list
and/or propose a pull request to update this guide. Thanks!
\ No newline at end of file
diff --git a/website/community/how-to-release/release-manager-preparation.md
b/website/community/how-to-release/release-manager-preparation.md
new file mode 100644
index 000000000..e189e8751
--- /dev/null
+++ b/website/community/how-to-release/release-manager-preparation.md
@@ -0,0 +1,208 @@
+---
+title: Release Manager Preparation
+sidebar_position: 1
+---
+
+# Release Manager Preparation
+
+It is important that the release manager is well prepared before initiating
the release process. This page provides a checklist of tasks that should be
completed in advance.
+
+We recommend that the release manager be a committer or a PPMC member, as they
typically have the necessary permissions and in-depth understanding of the
project. However, any contributor familiar with the Fluss project and who has
the required access rights may serve as the release manager.
+
+Note: The following setup is a one-time configuration required for release
preparation.
+
+## Environment Setup
+
+This release process is suggested to operate on MacOS or Linux systems, and
the following tools are required:
+
+- Java 8
+- Apache Maven 3.8.6
+- GnuPG 2.x
+- Git
+- SVN
+
+## GPG Key
+
+You need to have a GPG key to sign the release artifacts. Please be aware of
the ASF-wide [release signing
guidelines](https://www.apache.org/dev/release-signing.html). If you don’t have
a GPG key associated with your Apache account, please create one according to
the guidelines.
+
+### Generate a GPG Key
+
+Following is a quick setup guide for generating GPG key.
+
+Install GPG:
+
+```
+sudo apt install gnupg2
+```
+
+Generate a GPG key. Please use your apache name and email for generate key.
+
+```bash
+$ gpg --full-gen-key
+gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+Please select what kind of key you want:
+ (1) RSA and RSA (default)
+ (2) DSA and Elgamal
+ (3) DSA (sign only)
+ (4) RSA (sign only)
+ (14) Existing key from card
+Your selection? 1 # input 1
+RSA keys may be between 1024 and 4096 bits long.
+What keysize do you want? (2048) 4096 # input 4096
+Requested keysize is 4096 bits
+Please specify how long the key should be valid.
+ 0 = key does not expire
+ <n> = key expires in n days
+ <n>w = key expires in n weeks
+ <n>m = key expires in n months
+ <n>y = key expires in n years
+Key is valid for? (0) 0 # input 0
+Key does not expire at all
+Is this correct? (y/N) y # input y
+
+GnuPG needs to construct a user ID to identify your key.
+
+Real name: Jark Wu # input your name
+Email address: [email protected] # input your email
+Comment: CODE SIGNING KEY # input some annotations, optional
+You selected this USER-ID:
+ "Jark Wu <[email protected]>"
+
+Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O # input O
+We need to generate a lot of random bytes. It is a good idea to perform
+some other action (type on the keyboard, move the mouse, utilize the
+disks) during the prime generation; this gives the random number
+generator a better chance to gain enough entropy.
+We need to generate a lot of random bytes. It is a good idea to perform
+some other action (type on the keyboard, move the mouse, utilize the
+disks) during the prime generation; this gives the random number
+generator a better chance to gain enough entropy.
+
+# Input the security key
+┌──────────────────────────────────────────────────────┐
+│ Please enter this passphrase │
+│ │
+│ Passphrase: _______________________________ │
+│ │
+│ <OK> <Cancel> │
+└──────────────────────────────────────────────────────┘
+# key generation will be done after your inputting the key with the following
output
+gpg: key 9D27AF4D799 marked as ultimately trusted
+gpg: revocation certificate stored as
'/Users/wuchong/.gnupg/openpgp-revocs.d/3ADAEEABE828406F6AB2338B832539D27AF4D799.rev'
+public and secret key created and signed.
+
+pub rsa4096 2025-08-07 [SC]
+ 3ADAEEABE828406F6AB2338B832539D27AF4D799
+uid Jark Wu (CODE SIGNING KEY) <[email protected]>
+sub rsa4096 2025-08-07 [E]
+```
+
+### Upload GPG public Key to Apache KEYS
+
+Determine your Apache GPG Key and Key ID, as follows:
+
+```bash
+gpg --list-keys
+```
+
+This will list your GPG keys. One of these should reflect your Apache account,
for example:
+
+```
+--------------------------------------------------
+pub 2048R/845E6689 2016-02-23
+uid Nomen Nescio <[email protected]>
+sub 2048R/BA4D50BE 2016-02-23
+```
+
+Here, the key ID is the 8-digit hex string in the pub line: 845E6689.
+
+Now, add your Apache GPG key to the Flink’s KEYS file in the
[release](https://dist.apache.org/repos/dist/release/incubator/fluss/KEYS)
repository at [dist.apache.org](https://dist.apache.org). Follow the
instructions listed at the top of these files. (Note: Only PPMC members have
write access to the release repository. If you end up getting 403 errors ask on
the mailing list for assistance.) PPMC member can refer following scripts to
add your Apache GPG key to the KEYS in the release re [...]
+
+```
+svn co https://dist.apache.org/repos/dist/release/incubator/fluss fluss-dist
+cd fluss-dist
+(gpg --list-sigs <YOUR_KEY_ID> && gpg --armor --export <YOUR_KEY_ID>) >> KEYS
+svn ci -m "[fluss] Add <YOUR_NAME>'s public key"
+```
+
+To send the key to the Ubuntu key-server, Apache Nexus needs it to validate
published artifacts:
+
+```
+gpg --keyserver hkps://keyserver.ubuntu.com --send-keys <YOUR KEY ID HERE>
+```
+
+Configure git to use this key when signing code by giving it your key ID, as
follows:
+
+```
+git config --global user.signingkey 845E6689
+```
+
+You may drop the `--global` option if you’d prefer to use this key for the
current repository only.
+
+You may wish to start `gpg-agent` to unlock your GPG key only once using your
passphrase. Otherwise, you may need to enter this passphrase hundreds of times.
The setup for `gpg-agent` varies based on operating system, but may be
something like this:
+
+```
+eval $(gpg-agent --daemon --no-grab --write-env-file $HOME/.gpg-agent-info)
+export GPG_TTY=$(tty)
+export GPG_AGENT_INFO
+```
+
+### Upload the GPG public key to your GitHub account (Optional)
+
+Enter https://github.com/settings/keys to add your GPG key.
+Please remember to bind the email address used in the GPG key to your GitHub
account (https://github.com/settings/emails) if you find "unverified" after
adding it.
+
+## Access to Apache Nexus repository
+
+Configure access to the [Apache Nexus
repository](https://repository.apache.org/), which enables final deployment of
releases to the Maven Central Repository.
+
+1. You log in with your Apache account.
+2. Confirm you have appropriate access by finding `org.apache.fluss` under
`Staging Profiles`.
+3. Navigate to your Profile (top right dropdown menu of the page).
+4. Choose `User Token` from the dropdown, then click `Access User Token`. Copy
a snippet of the Maven XML configuration block.
+5. Insert this snippet twice into your global Maven `settings.xml` file,
typically `${HOME}/.m2/settings.xml`. The end result should look like this,
where `TOKEN_NAME` and `TOKEN_PASSWORD` are your secret tokens:
+
+```xml
+<settings>
+ <servers>
+ <server>
+ <id>apache.releases.https</id>
+ <username>TOKEN_NAME</username>
+ <password>TOKEN_PASSWORD</password>
+ </server>
+ <server>
+ <id>apache.snapshots.https</id>
+ <username>TOKEN_NAME</username>
+ <password>TOKEN_PASSWORD</password>
+ </server>
+ </servers>
+</settings>
+```
+
+## GNU Tar Setup for Mac
+
+Skip this step if you are not using a Mac. The default tar application on Mac
does not support GNU archive format and defaults to Pax. This bloats the
archive with unnecessary metadata that can result in additional files when
decompressing (see 1.15.2-RC2 vote thread). Install gnu-tar and create a
symbolic link to use in preference of the default tar program.
+
+```bash
+brew install gnu-tar
+ln -s /opt/homebrew/bin/gtar /usr/local/bin/tar
+# Make sure which directory "gtar" is installed to, at the time of writing it
is "/opt/homebrew/bin/gtar"
+which tar
+```
+
+
+## Further reading
+
+It's recommended but not mandatory to read following documents before making a
release to know more details about apache release:
+
+- Release policy: https://www.apache.org/legal/release-policy.html
+- Incubator release: http://incubator.apache.org/guides/releasemanagement.html
+- TLP release: https://infra.apache.org/release-distribution
+- Release sign: https://infra.apache.org/release-signing.html
+- Release publish: https://infra.apache.org/release-publishing.html
+- Release download pages: https://infra.apache.org/release-download-pages.html
+- Publishing maven artifacts:
https://infra.apache.org/publishing-maven-artifacts.html
+
diff --git
a/website/community/how-to-release/verifying-a-fluss-shaded-release.md
b/website/community/how-to-release/verifying-a-fluss-shaded-release.md
new file mode 100644
index 000000000..23f418d98
--- /dev/null
+++ b/website/community/how-to-release/verifying-a-fluss-shaded-release.md
@@ -0,0 +1,98 @@
+---
+title: Verifying a Fluss Shaded Release
+sidebar_position: 3
+---
+
+# Verifying a Fluss Shaded Release
+
+## Validating distributions
+
+Release vote email includes links to:
+
+- Distribution archives (source, admin, server) on dist.apache.org
+- Signature files (.asc)
+- Checksum files (.sha512)
+- KEYS file
+
+After downloading the distributions archives, signatures, checksums, and KEYS
file, here are the instructions on how to verify signatures, checksums.
+
+## Verifying signatures
+
+First, import the keys in your local keyring:
+
+```bash
+curl https://downloads.apache.org/incubator/fluss/KEYS -o KEYS
+gpg --import KEYS
+```
+
+Next, verify all `.asc` files:
+
+```bash
+for i in *.tgz; do echo $i; gpg --verify $i.asc $i; done
+```
+If the verification is successful, you will see a message like this:
+
+```
+fluss-shaded-1.0-incubating-src.tgz
+gpg: Signature made Mon 01 Jan 2024 12:00:00 PM UTC
+gpg: using RSA key E2C45417BED5C104154F341085BACB5AEFAE3202
+gpg: Good signature from "Jark Wu (CODE SIGNING KEY) <[email protected]>"
+```
+
+## Verifying checksums
+
+Next, verify all the checksums:
+
+```bash
+for i in *.tgz; do echo $i; sha512sum --check $i.sha512*; done
+```
+
+If the verification is successful, you will see a message like this:
+
+```
+fluss-shaded-1.0-incubating-src.tgz
+fluss-shaded-1.0-incubating-src.tgz: OK
+```
+
+## Verifying build
+
+Unzip the source release archive (`fluss-shaded-1.0-incubating-src.tgz`), and
verify that the source release builds correctly (may with different Java
version and Maven version), you can run the following commands:
+
+```bash
+mvn clean package -DskipTests
+```
+
+## Verifying LICENSE/NOTICE
+
+Unzip the source release archive, and verify that:
+
+1. Check the LICENSE and NOTICE files are correct.
+2. All files have ASF license headers if necessary.
+3. All dependencies must be checked for their license and the license must be
ASL 2.0 compatible (http://www.apache.org/legal/resolved.html#category-x)
+4. Compatible non-ASL 2.0 licenses should be contained in the
`META-INF/licenses` directory of the respective module
+5. The LICENSE and NOTICE files in the root directory refer to dependencies in
the source release, i.e., files in the git repository (such as fonts, css,
JavaScript, images)
+
+
+## Testing Against Staged Maven Artifacts
+
+Update the root `pom.xml` of the maven project (like the apache/fluss project)
to include the staged repository in the `<repositories>` section. You can do
this by adding a new repository entry like this:
+
+```xml
+<repositories>
+ <repository>
+ <id>fluss-shaded-staging</id>
+ <name>Temporary Staging Repo</name>
+
<url>https://repository.apache.org/content/repositories/orgapachefluss-${STAGED_REPO_ID}/</url>
+ </repository>
+</repositories>
+```
+
+And then you can use the staged maven artifacts as dependencies in the project
and verify the new dependencies work.
+
+## Voting
+
+Votes are cast by replying on the vote email on the dev mailing list, with
either +1, 0, -1.
+
+In addition to your vote, it’s customary to specify if your vote is binding or
non-binding. Only members of the PPMC and mentors have formally binding votes,
and IPMC on the vote on the Incubator general mailing list. If you’re unsure,
you can specify that your vote is non-binding. You can find more details on
https://www.apache.org/foundation/voting.html.
+
+Besides, it is recommended to include a list of checklist you have verified
for your vote. This helps the community to understand what you have checked and
what is still missing.
