We have a private function which returns a hard-coded version number which is used when we build the user-agent for requests originating from the client. This is difficult to maintain while releasing because Go releases are handled through GitHub and Git tags, and requires us to keep things in sync manually.
I also missed updating this for v1.0.0, so it needs to be bumped anyways.
We're also missing any kind of "official" release process for the Go client, which would be beneficial in standardizing versioning and the process for releasing the client now that we're >v1.0.0. I'd rather we have a GitHub workflow similar to the other clients even if it primarily involves bumping a hard-coded version file, and pushing a tag.
Solution
Replace the old hard-coded version with a new internal/version.go file which packages and holds internal.Version to be used within the client. This is the file that CI will manage and commit updates towards as we bump versions.
Add new GitHub action .github/actions/bump-version allowing us to easily bump the currentVersion using a specific releaseLevel (major, minor, patch), isPrerelease, and prereleaseSuffix if desired. This action was something @jhamon originally added to the pinecone-python-client. I've lifted it here with minor alterations to support just returning a new version_tag rather than modifying a file using fs which it does in the Python repo.
I would like to work on getting this action shared properly through GitHub so that we can reuse with one source of truth, but that will take some additional work beyond the scope of this fix. I've added a ticket: https://app.asana.com/0/1203260648987893/1208039955828667/f
Add new GitHub workflow ./github/workflows/release.yaml to facilitate releasing the Go SDK by updating internal/version.go, and pushing the new tag. For prerelease, we just push the tag without committing.
Type of Change
[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[X] Infrastructure change (CI configs, etc)
[ ] Non-code change (docs, etc)
[ ] None of the above: (explain here)
Test
I'll need to get the CI files into source before I can test the actual release process. My thinking here is I've updated the hard-coded value to the current v1.0.0, and I'd like to release a v1.0.1 to fix the current problem with the user-agent not matching. I think this is reasonable, but let me know if you don't agree.
The bump-version action itself was lifted directly from @jhamon's work including unit tests, so I think that is mostly safe. I'd spend the bulk of the review looking at my approach in release.yaml.
To see the specific tasks where the Asana app for GitHub is being used, see below:
Problem
We have a private function which returns a hard-coded version number which is used when we build the user-agent for requests originating from the client. This is difficult to maintain while releasing because Go releases are handled through GitHub and Git tags, and requires us to keep things in sync manually.
I also missed updating this for
v1.0.0, so it needs to be bumped anyways.We're also missing any kind of "official" release process for the Go client, which would be beneficial in standardizing versioning and the process for releasing the client now that we're >v1.0.0. I'd rather we have a GitHub workflow similar to the other clients even if it primarily involves bumping a hard-coded version file, and pushing a tag.
Solution
internal/version.gofile which packages and holdsinternal.Versionto be used within the client. This is the file that CI will manage and commit updates towards as we bump versions..github/actions/bump-versionallowing us to easily bump thecurrentVersionusing a specificreleaseLevel(major, minor, patch),isPrerelease, andprereleaseSuffixif desired. This action was something @jhamon originally added to the pinecone-python-client. I've lifted it here with minor alterations to support just returning a newversion_tagrather than modifying a file usingfswhich it does in the Python repo../github/workflows/release.yamlto facilitate releasing the Go SDK by updatinginternal/version.go, and pushing the new tag. For prerelease, we just push the tag without committing.Type of Change
Test
I'll need to get the CI files into source before I can test the actual release process. My thinking here is I've updated the hard-coded value to the current
v1.0.0, and I'd like to release av1.0.1to fix the current problem with the user-agent not matching. I think this is reasonable, but let me know if you don't agree.The
bump-versionaction itself was lifted directly from @jhamon's work including unit tests, so I think that is mostly safe. I'd spend the bulk of the review looking at my approach inrelease.yaml.