chore: add releasing guide

Signed-off-by: Mathew Wicks <[email protected]>

Author: thesuperzapper

README.md

@@ -8,7 +8,10 @@ This repo contains the command line interface (CLI) for [deployKF](https://githu
 
 You can install the `deploykf` CLI by downloading the appropriate binary for your OS from the [releases page](https://github.com/deployKF/cli/releases).
  - You may wish to rename the binary to `deploykf` (or `deploykf.exe` on Windows).
- - On Unix-like systems, you may need to make the binary executable by running `chmod +x deploykf`.
+ - You may need to make the binary executable on Linux/macOS by running `chmod +x deploykf`.
+ - You may also wish to move the binary to a directory that is in your `PATH` environment variable. 
+    - On Linux/macOS you might run `sudo mv deploykf /usr/local/bin/`.
+    - On Windows you might run `move deploykf.exe C:\Windows\System32\`.
 
 ## Usage
 
@@ -32,21 +35,3 @@ Here are some helpful commands when developing the CLI:
 - `make install`: Installs the binary to `/usr/local/bin`.
 - `make lint`: Runs `golangci-lint` against the codebase to check for errors.
 - `make lint-fix`: Attempts to automatically fix any linting errors found.
-
-## Releasing
-
-To release a new version of the CLI, follow these steps:
-
-1. For a new minor or major release, create a `release-*` branch first.
-    - For example, for the `v0.2.0` release, create a new branch called `release-0.2`. 
-    - This allows for the continued release of bug fixes to older CLI versions.
-2. Create a new tag on the appropriate release branch for the version you are releasing.
-    - Ensure you sign the tag with your GPG key. 
-       - You can do this by running `git tag -s v0.1.1 -m "v0.1.1"`.
-       - You can verify the tag by running `git verify-tag v0.1.1`.
-    - For instance, you might create `v0.1.1` or `v0.1.1-alpha.1` on the `release-0.1` branch.
-    - Remember to create tags only on the `release-*` branches, not on the `main` branch.
-3. When a new semver tag is created, a workflow will automatically create a GitHub draft release.
-    - The release will include binaries and corresponding SHA256 checksums for all supported platforms.
-    - Don't forget to add the changelog to release notes.
-4. Manually publish the draft release.

RELEASING.md

@@ -0,0 +1,21 @@
+# Releasing Guide
+
+This guide is intended for maintainers who want to make a new release of the deployKF CLI.
+
+1. For a new minor or major release, create a `release-*` branch first.
+    - For example, for the `v0.2.0` release, create a new branch called `release-0.2`. 
+    - This allows for the continued release of bug fixes to older versions.
+2. Create a new tag on the appropriate release branch for the version you are releasing.
+    - For instance, you might create `v0.1.1` or `v0.1.1-alpha.1` on the `release-0.1` branch.
+    - Ensure you ONLY create tags on the `release-*` branches, not on the `main` branch.
+    - Remember to sign the tag with your GPG key. 
+       - You can do this by running `git tag -s v0.1.1 -m "v0.1.1"`.
+       - You can verify the tag signature by running `git verify-tag v0.1.1`.
+    - Ensure you ONLY push the specific tag you want to release. 
+       - For example, if you want to release `v0.1.1`, you should run `git push origin v0.1.1`.
+       - Do NOT run `git push origin --tags` or `git push origin main`.
+3. When a new semver tag is created, a workflow will automatically create a GitHub draft release.
+    - The release will include the binaries and corresponding SHA256 checksums for all supported platforms.
+    - Don't forget to add a changelog to the release description. 
+       - You can use the "generate release notes" feature of GitHub to help you with this.
+4. Manually publish the draft release.