Implement automated publishing

[toddbaert]

We need automated publishing of the Golang SDK. Things to consider:

• versioning (alpha for now: 0.0.xxx)
• naming
• Anything else?

https://go.dev/doc/modules/publishing

Blocked by: #13

[skyerus]

Should we automate the creation of a release on every merge to main?
Or should we expect the releases to be created manually and have an action that listens to that event?

@toddbaert @beeme1mr @james-milligan

[toddbaert]

With the Java SDK and the Node SDK, we automate every push to main, but that creates a SNAPSHOT/prerelease build respectively. These aren't "official" releases, but release-candidates.

I think if we build something from main, it would ideally be like that. Seems like similar idioms exist in golang: https://go.dev/doc/modules/release-workflow#pre-releaseo

[skyerus]

I can see from the Node SDK implementation that no "official" github tag/release is created as npm handles the package's release process.
Golang's process works differently in that as long as the module is public it is directly accessible. For example one can go get the module at any commit using its hash:
go get github.com/open-feature/golang-sdk@7c8080bebe44e8e0bb7eb25645e5da76a6296d03
The act of "publishing" here would be to create a tag. If we only create a tag (without a release) then in my opinion this would behave as a release candidate.

[warber]

Hi, just wanted to mention that the very popular goreleaser project also supports "releasing" libraries. Using it in the context of github actions, this would just give us a little neat automation around changelog generation and creating the github releases. I've just played with it recently using a dummy repository and it worked quite nice.

[skyerus]

Hi, just wanted to mention that the very popular goreleaser project also supports "releasing" libraries. Using it in the context of github actions, this would just give us a little neat automation around changelog generation and creating the github releases. I've just played with it recently using a dummy repository and it worked quite nice.

Thank you for pointing us to that @warber, I followed your footsteps and forked the example repo to have a play with it myself.

We can combine github-tag-action with goreleaser to automate the creation of a tag on merge to main and subsequently the go release process using the created tag. We can mark the releases as prerelease in the .goreleaser.yaml config file until the first official release.

The github tag action defaults to bumping by a minor version (e.g. v0.1.0 to v0.2.0) but you can specify how to bump the version in the commit message (#patch / #minor / #major).

I've created a PR with the config needed to make the above happen.

After discussion we've opted for the approach of manual tag creation (must be prefixed with v e.g. v0.1.9) that triggers the goreleaser process. I've created a PR with the config needed to make this happen.