Auto-release current major version (ex: @v2) (#91)

.github/workflows/auto-git-release-production.yml

@@ -48,7 +48,7 @@ jobs:
           echo "previous_commit: ${{steps.next_semantic_version.outputs.previous_commit}}"
           echo "current_commit: ${{steps.next_semantic_version.outputs.current_commit}}"
 
-      - name: Creating Git release tag for the ${{steps.next_semantic_version.outputs.version_tag}} version
+      - name: Creating Git release tag for the "${{steps.next_semantic_version.outputs.version_tag}}" version
         uses: softprops/action-gh-release@v1
         with: # See https://github.com/softprops/action-gh-release#-customizing
           token: "${{ secrets.GITHUB_TOKEN }}"
@@ -69,3 +69,14 @@ jobs:
           generate_release_notes: true
           files: |
             CHANGELOG.md
+
+      - name: Updating Git release tag for the major "${{steps.next_semantic_version.outputs.major}}" version
+        uses: softprops/action-gh-release@v1
+        with: # See https://github.com/softprops/action-gh-release#-customizing
+          token: "${{ secrets.GITHUB_TOKEN }}"
+          tag_name: ${{steps.next_semantic_version.outputs.major}}
+          name: "${{steps.next_semantic_version.outputs.major}} latest release (auto-update)"
+          prerelease: false
+          generate_release_notes: true
+          files: |
+            CHANGELOG.md

.github/workflows/auto-git-release-staging.yml

@@ -68,3 +68,14 @@ jobs:
           generate_release_notes: true
           files: |
             CHANGELOG.md
+
+      - name: Updating Git release tag for the major "${{steps.next_semantic_version.outputs.major}}-rc" version
+        uses: softprops/action-gh-release@v1
+        with: # See https://github.com/softprops/action-gh-release#-customizing
+          token: "${{ secrets.GITHUB_TOKEN }}"
+          tag_name: "${{steps.next_semantic_version.outputs.major}}-rc"
+          name: "${{steps.next_semantic_version.outputs.major}}-rc latest release (auto-update)"
+          prerelease: true
+          generate_release_notes: true
+          files: |
+            CHANGELOG.md

README.md

@@ -15,7 +15,7 @@ jobs:
   wait-for-vercel-deployment:
     runs-on: ubuntu-22.04
     steps:
-      - uses: UnlyEd/github-action-await-vercel@latest # TODO best practices recommend to use a fixed version instead of @latest for production usage (i.e: @v1.2.32)
+      - uses: UnlyEd/github-action-await-vercel@v1 # TODO best practices recommend to use a fixed version instead of @v1 for production usage (i.e: @v1.2.32)
         id: await-vercel
         env:
           VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
@@ -100,7 +100,7 @@ In the below example, we show you how to:
 
 1. **Step 1**: Forward `VERCEL_DEPLOYMENT_URL` as an ENV variable, using ` >> $GITHUB_ENV"` which stores the value into the GitHub Actions env vars.
     Of course, you might do it differently. It doesn't really matter as long as `VERCEL_DEPLOYMENT_URL` is set.
-1. **Step 2**: Then, we use the `UnlyEd/github-action-await-vercel@latest` GitHub Action, which waits for the deployment url to be ready.
+1. **Step 2**: Then, we use the `UnlyEd/github-action-await-vercel@v1` GitHub Action, which waits for the deployment url to be ready.
 1. **Step 3**: Finally, we show an example on how to read the deployment's information returned by the Vercel API (which have been forwarded).
 
 ```yaml
@@ -117,7 +117,7 @@ jobs:
       - name: Retrieve deployment URL (example on how to set an ENV var)
         run: "echo VERCEL_DEPLOYMENT_URL=nextjs-bzyss249z.vercel.app >> $GITHUB_ENV"
 
-      - uses: UnlyEd/github-action-await-vercel@latest # TODO best practices recommend to use a fixed version instead of @latest for production usage (i.e: @v1.2.32)
+      - uses: UnlyEd/github-action-await-vercel@v1 # TODO best practices recommend to use a fixed version instead of @v1 for production usage (i.e: @v1.2.32)
         id: await-vercel
         env:
           VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
@@ -201,11 +201,34 @@ Our versioning process is completely automated, any changes landing on the `main
 
 ## Releases versions:
 
-- We do not provide major versions that are automatically updated (e.g: `v1`).
-- We only provide tags/releases that are not meant to be changed once released (e.g: `v1.1.0`).
+The examples above use an auto-updated major version tag (`@v1`).
+It is also possible to use the `@latest` and `@latest-rc` tags.  (RC stands for "Release candidate", which is similar to a Beta version)
 
-> As utility, we provide a special [`latest`](../../releases/tag/latest) tag which is automatically updated to the latest release.
-> _This tag/release is **not meant to be used in production systems**, as it is not reliable (might jump to the newest MAJOR version at any time)._
+While those options can be useful, we intend to give some "production-grade" best practices. 
+
+- **Do NOT use `@latest` for production**, ever. While only "supposed-to-be-stable" versions will be tagged as `@latest`, it could harbor bugs nonetheless.
+- You can use auto-upgrading major version, such as `@v1`, but this is not a best practice, see our explanations below.
+
+### Special tags and production-grade apps best practices
+
+Here are a few useful options you can use to pin a more-or-less specific version of our GitHub Action, alongside some "production-grade" best practices.
+
+- `@{COMMIT-SHA}`, e.g: `@1271dc3fc4c4c8bc62ba5a4e248dac95cb82d0e3`, recommended for all production-grade apps, it's the only truly safe way to pinpoint a version that cannot change against your will (**SAFEST**)
+- `@{MAJOR}-{MINOR}-{PATCH}`, e.g: `@v1.2.31`, while not as safe as the `COMMIT-SHA` way, it's what most people use (SAFER)
+- `@{MAJOR}`, e.g: `@v1`, can be used on production, but we do not advise to do so (SAFE-ISH)
+- `@{MAJOR}-rc`, e.g: `@v1-rc`, **reserved for development mode**, useful when debugging on a specific prerelease version (UNSAFE)
+- `@latest`, **reserved for development mode**, useful when debugging (UNSAFE)
+- `@latest-rc`, **reserved for development mode**, useful when debugging on prerelease versions (UNSAFE)
+
+**"But, what is the issue with the `@{MAJOR}-{MINOR}-{PATCH}` way to pin a specific version"?**
+
+> Well, if our repositories gets hacked by a 3rd party, **they can easily change all Git tags to a different commit**, which could contain malicious code.
+
+That's why **pinning a specific commit SHA is the only truly safe option**. This way, the code you're using **cannot be changed against your will**.
+
+Most people won't care about this and will use a MAJOR version tag instead anyway, such as `@v1`. It's common, but not the best practice.
+
+It all comes down to the risks you're ready to take, and it's up to you to decide what's best in your situation.
 
 ---