Preparing for next developer iteration, 4.3.1. (#634)

Signed-off-by: dblock <[email protected]>

CHANGELOG.md

@@ -2,6 +2,22 @@
 
 Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
+## [Unreleased]
+
+### Added
+
+### Changed
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+### Security
+
+### Dependencies
+
 ## [4.3.0]
 
 ### Added
@@ -278,6 +294,7 @@ Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 - Bumps `github.com/stretchr/testify` from 1.8.0 to 1.8.1
 - Bumps `github.com/aws/aws-sdk-go` from 1.44.45 to 1.44.132
 
+[Unreleased]: https://github.com/opensearch-project/opensearch-go/compare/v4.3.0...HEAD
 [4.3.0]: https://github.com/opensearch-project/opensearch-go/compare/v4.2.0...v4.3.0
 [4.2.0]: https://github.com/opensearch-project/opensearch-go/compare/v4.1.0...v4.2.0
 [4.1.0]: https://github.com/opensearch-project/opensearch-go/compare/v4.0.0...v4.1.0

RELEASING.md

@@ -33,14 +33,14 @@ Repositories create consistent release labels, such as `v1.0.0`, `v1.1.0` and `v
 
 The release process is standard across repositories in this org and is run by a release manager volunteering from amongst [MAINTAINERS](MAINTAINERS.md).
 
-1. Ensure that the version in [version.go](internal/version/version.go) is correct for the next release. 
+1. Ensure that the version in [version.go](internal/version/version.go) is correct for the next release. The example here releases version 4.3.0.
 2. For major version releases, ensure that all references are up-to-date, e.g. `github.com/opensearch-project/opensearch-go/v4`, see [opensearch-go#444](https://github.com/opensearch-project/opensearch-go/pull/444).
 3. Edit the [CHANGELOG](CHANGELOG.md) and replace the `Unreleased` section with the version about to be released.
 4. Add a comparison link to the new version at the bottom of the [CHANGELOG](CHANGELOG.md).
 5. Create a pull request with the changes into `main`, e.g. [opensearch-go#443](https://github.com/opensearch-project/opensearch-go/pull/443).
-6. Create a tag, e.g. `v3.0.1`, and push it to the GitHub repo. This [makes the new version available](https://go.dev/doc/modules/publishing) on [pkg.go.dev](https://pkg.go.dev/github.com/opensearch-project/opensearch-go/v3).
+6. Create a tag, e.g. `v4.3.0`, and push it to the GitHub repo. This [makes the new version available](https://go.dev/doc/modules/publishing) on [pkg.go.dev](https://pkg.go.dev/github.com/opensearch-project/opensearch-go/v4).
 7. Draft and publish a [new GitHub release](https://github.com/opensearch-project/opensearch-go/releases/new) from the newly created tag.
-8. Create a new `Unreleased` section in the [CHANGELOG](CHANGELOG.md), increment version in [version.go](internal/version/version.go) to the next developer iteration (e.g. `3.0.2`), and make a pull request with this change into `main`, e.g. [opensearch-go#448](https://github.com/opensearch-project/opensearch-go/pull/448).
+8. Create a new `Unreleased` section in the [CHANGELOG](CHANGELOG.md), increment version in [version.go](internal/version/version.go) to the next developer iteration (e.g. `4.3.1`), and make a pull request with this change into `main`, e.g. [opensearch-go#448](https://github.com/opensearch-project/opensearch-go/pull/448).
     ```
     ## [Unreleased]
 
@@ -58,3 +58,4 @@ The release process is standard across repositories in this org and is run by a
 
     ### Dependencies
     ```
+9. Run `go list` with the new version to refresh [pkg.go.dev](https://pkg.go.dev/github.com/opensearch-project/opensearch-go/v4), e.g. `go list -m github.com/opensearch-project/opensearch-go/[email protected]`.

internal/version/version.go

@@ -27,4 +27,4 @@
 package version
 
 // Client returns the client version as a string.
-const Client = "4.3.0"
+const Client = "4.3.1"