Currently, all integration modules (gin/, fiber/, etc) are released in lock-step with the root SDK. Every craft publish bumps every sub-module's go.mod to require the new root version and creates tags for all integrations, even when they haven't changed. This causes two issues:
- Integrations get a new tag when no actual changes have happened.
- Integrations have version coupling with the root SDK. Users can't adopt a newer version of the SDK independently.
Possible Solution
The easiest solution would be to automate version bumping based on changes that happened and conditionally create a tag for each sub-module, but craft doesn't support conditional targets. Then the other possible options are:
- different
craft.yml configs for each integration, with the drawback of complexity and maintaining 15+ different configs.
- keep craft for root sdk releases since it helps with changelog management and version bumping, but for Go the release process is really simple since we don't publish to a registry (we only need to create a git tag), so add a separate release action for the integrations.
Option 2 is the best path, but splits the release workflow into two paths which isn't really obvious.
Currently, all integration modules (gin/, fiber/, etc) are released in lock-step with the root SDK. Every craft publish bumps every sub-module's go.mod to require the new root version and creates tags for all integrations, even when they haven't changed. This causes two issues:
Possible Solution
The easiest solution would be to automate version bumping based on changes that happened and conditionally create a tag for each sub-module, but craft doesn't support conditional targets. Then the other possible options are:
craft.ymlconfigs for each integration, with the drawback of complexity and maintaining 15+ different configs.Option 2 is the best path, but splits the release workflow into two paths which isn't really obvious.