Implement a release process for this repo.
Strawman: We create and push a semver git tag at a point in version control history designating a notable release of this SDK (eg v4.0.0). Just having versioned GitHub URLs (courtesy the tag) is helpful, for example for upstream documentation (eg https://spinframework.dev). However, we should also add a GitHub workflow that automates publishing the versioned sdk package to pypi.org.
There's also the subject of templates, which hinges (or used to) on pushing a spin/templates/<spin version> tag to designate which template version is compatible with which spin version.
Meanwhile, this repo also has a handful of preexisting git tags and corresponding GitHub releases which appear to have been only for the older versions of the SDK when it relied on a Spin plugin (py2wasm). Not sure if we wish to proactively clean those up (has it been enough time?) or fine to leave be (soon superceded by releases per this effort).
Implement a release process for this repo.
Strawman: We create and push a semver git tag at a point in version control history designating a notable release of this SDK (eg v4.0.0). Just having versioned GitHub URLs (courtesy the tag) is helpful, for example for upstream documentation (eg https://spinframework.dev). However, we should also add a GitHub workflow that automates publishing the versioned sdk package to pypi.org.
There's also the subject of templates, which hinges (or used to) on pushing a
spin/templates/<spin version>tag to designate which template version is compatible with which spin version.Meanwhile, this repo also has a handful of preexisting git tags and corresponding GitHub releases which appear to have been only for the older versions of the SDK when it relied on a Spin plugin (
py2wasm). Not sure if we wish to proactively clean those up (has it been enough time?) or fine to leave be (soon superceded by releases per this effort).