[All SDKs] Automate SDK release process to enable Continuous Delivery

[dyeam0]

Checklist

• I agree to the terms within the OpenFGA Code of Conduct.

Describe the problem you'd like to have solved

Currently, releasing a new version of an OpenFGA SDK is a manual process. It requires manual steps from the team, including manual version updates, changelog generation, individual release triggers, and possibly other manual steps. This manual overhead creates several points of friction:

• Release Velocity: Time to delivery of features and/or fixes to users is high if new versions are not released for an extended period of time.
• Maintainer Pain and Overhead: The effort required to ship a single PR in a release is disproportionately high.
• Consistency: Manual steps have a small possibility of omitted changelog entries across the various language SDKs. Not common, but it has happened on occasion.

We want to change from requiring the team's periodic decision to "cut a release", toward a Continuous Delivery (CD) model (with manual trigger) where the SDKs are in a deliverable state, where releasing a new version is as simple as metaphorically "clicking the button". This would enable a situation where it is feasible to release upon every PR merged, if so desired.

Describe the ideal solution

We need to automate the logic and associated CI/CD workflows to support a near "zero-touch" release process for all languages. It is not completely "zero-touch" as Continuous Deployment is not the goal. The goal is to reach a state where:

1. Automated Preparation: Every merged PR prepares the SDK for release without manual code or configuration changes.
2. Automated Versioning: The system should default to an incremental minor version bump. However, we must provide an override mechanism capable of specifying a major, patch, or beta release version at the time of triggering.
3. Manual Gate, Automated Execution: While the process should be fully automated, a human still performs the final "manual trigger" (ex., via a GitHub Actions button) to execute the release process.
4. Language Agnostic: As much of the core automation logic should be implemented in the SDK generator so that it can be applied consistently across Go, .NET, JS, Python, and Java.
5. Language Specifics: Language-specific changes, ex. handling of release artifacts should be implemented in the language repos.

Alternatives and current workarounds

• Current State: The process requires manual coordination across repositories, including manual updates to version files, manual Git tag creation, and manual triggers in each repository.
• Workaround: Delaying releases and batching PRs until multiple changes accumulate to justify the manual overhead. This increases the time to delivery for features and/or fixes, preventing users from receiving improvements as soon as they are ready.

References

No response

Additional context

No response