From 75f6c460e123009bff03760b734f41d529f6ed9f Mon Sep 17 00:00:00 2001
From: mohitrajain <20745774+mohitrajain@users.noreply.github.com>
Date: Fri, 28 Feb 2025 17:10:11 +0100
Subject: [PATCH] docs(docs.wire.com): WPB-15365 fix the release docs

---
 .github/workflows/build.yaml | 1 +
 Release.md                   | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
index 611b6d4..f5d9888 100644
--- a/.github/workflows/build.yaml
+++ b/.github/workflows/build.yaml
@@ -6,6 +6,7 @@ on:
       - main
     paths-ignore:
       - 'README.md'
+      - 'Release.md'
       - '.github/workflows/release.yaml'
 
 jobs:
diff --git a/Release.md b/Release.md
index b27ce15..2737c13 100644
--- a/Release.md
+++ b/Release.md
@@ -2,6 +2,8 @@
 
   - We follow GitHub's standard process for creating a `release`, as described in [GitHub's documentation](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release). We use the UI to create a release with the `Create new tag` option, which synchronizes the release creation with tag creation.
 
+  **NOTE:** Each release should initially be marked as `Set as a pre-release` to allow for verification of the release notes and artifacts. If the release workflow fails, you can fix the issues and create a new release before publishing the final release.
+
   - In the release notes, you can either specify the changes based on commits or use the `Generate release notes` feature to automatically compile a history of commits on the main branch.
 
   - All releases should be based on the *main* branch. For each release, changes to the main branch are aggregated through *pull requests*.