chore: make release doc more readable

development.md

@@ -31,11 +31,21 @@ Note: before running the script, ensure that through the CLI, you are logged int
 
 After confirming that your changes pass local testing:
 1. Clean up testing artifacts
-2. Create a PR. Once your PR has been merged, a Github Actions workflow (Docker Publish) will be triggered, to build, tag (with `stable`), and push
-   all example images. This ensures that all example images are using the most up-to-date version of the SDK, i.e. the one including your
-   changes.
+2. Create a PR. Once your PR has been merged, a Github Actions workflow (`Docker Publish`) will be triggered, to build, tag (with `stable`), and push
+all example images. This ensures that all example images are using the most up-to-date version of the SDK, i.e. the one including your changes
+3. If your SDK changes included modifications to any files in `pkg/info` or `pkg/apis/proto`, then get the commit SHA
+of the merged PR from the previous step, and in the Numaflow repo run:
+    ```shell
+    go get github.com/numaproj/numaflow-go@<commit-sha>
+   ```
+   Followed by:
+   ```shell
+   go mod tidy
+   ```
+   Create a PR for these changes. This is necessary as `numaflow-go` is a dependency of the Numaflow platform and the files
+   in these directories are imported and used by Numaflow.
 
 ### Adding a New Example
 
-If you add a new example, in order for it to be used by the Docker Publish workflow, add its path
+If you add a new example, in order for it to be used by the `Docker Publish` workflow, add its path
 to the `dockerfile_paths` matrix in `.github/workflows/build-push.yaml`.

releases.md

@@ -10,18 +10,43 @@ Ensure that this change is merged and included in the release.
 
 ### How to Release
 
-This can be done via the Github UI. In the `Releases` section of the Go SDK repo, click `Draft a new release`. Create an appropriate tag for the version number, using the [semantic versioning](https://semver.org/) specification, and select it. Make 
-the title the same as the tag. Click `Generate release notes` so that all the changes made since the last release are documented. If there are any major features or breaking
-changes that you would like to highlight as part of the release, add those to the description as well. Then set the release as either pre-release or latest, depending
-on your situation. Finally, click `Publish release`, and your version tag will be the newest release on the repository.
+This can be done via the Github UI. 
+1. In the `Releases` section of the Go SDK repo, click `Draft a new release`
+2. Create an appropriate tag for the version number following the [semantic versioning](https://semver.org/) specification and select it. The tag should be prefixed with a `'v'`
+3. Make the title the same as the tag 
+4. Click `Generate release notes` so that all the changes made since the last release are documented. If there are any major features or breaking
+changes that you would like to highlight as part of the release, add those to the description as well 
+5. Select `Set as the latest release` or `Set as a pre-release`, depending on your situation 
+6. Finally, click `Publish release`, and your version tag will be the newest release on the repository
 
 ### After Release
 
-Once a new version has been released, and its corresponding version tag exists on the remote repo, you want to update the `go.mod`
+1. Once a new version has been released, and its corresponding version tag exists on the remote repo, you want to update the `go.mod`
 files to reflect this new version:
-```shell
-./hack/update_examples.sh -u <version-tag>
-  ```
-After running the above, create a PR for the changes that the script made. Once merged, it will trigger the Docker Publish workflow.
+    ```shell
+    ./hack/update_examples.sh -u <version-tag>
+      ```
+2. Create a PR for the changes that the script made. Once merged, it will trigger the `Docker Publish` workflow.
 As a result, the correct SDK version will always be printed in the server information logs,
-and the example images will always be using the latest changes (due to the local references).
+and the example images will always be using the latest changes (due to the local references)
+3. Since the Go SDK is a dependency of Numaflow, once a new version has been released, the `go.mod` [file](https://github.com/numaproj/numaflow/blob/main/go.mod)
+in the root directory of the Numaflow repo should be updated
+   - If you set the SDK release as latest, in your Numaflow repo run:
+        ```shell
+         go get github.com/numaproj/numaflow-go@latest
+        ``` 
+        Followed by:
+        ```shell
+        go mod tidy
+        ```
+        Create a PR for these changes.
+
+   - If you set the SDK release as pre-release, in your Numaflow repo run:
+     ```shell
+      go get github.com/numaproj/numaflow-go@<commit-sha>
+      ``` 
+     Where `commit-sha` is the latest commit SHA in the SDK repo. Then run:
+     ```shell
+     go mod tidy
+     ```
+     Create a PR for these changes.