move Rust and Go SDKs to their own repos

[dicej]

These SDKs and their examples have moved to
https://github.com/fermyon/spin-rust-sdk and
https://github.com/fermyon/spin-go-sdk, respectively. The plan is to begin releasing them on their own cadence, independent of Spin releases. This will allow us to make breaking changes in semver-compatible major releases without tying such releases to a Spin major release, e.g. to target WASI 0.2.0.

Note that I've update the integration tests which use the Rust SDK to use the latest stable release (2.2.0) instead of a path-based dependency. Alternatively, we could point it at the main branch of the spin-rust-sdk Git repo, but that will require close coordination once we start making breaking changes to the API in that repo.

We may also want to move the Rust and Go templates to the new repos at some point. I've left them where they are for the time being.

Finally, I've removed the SDK-specific bits from release-process.md and the GitHub workflows. We'll need to move those things to their respective SDK repos. Reproducing the automated Go SDK tagging that feeds into the templates may require moving at least the Go templates as noted above.

[rylev]

One constant point of contention:

If there's differences between the version of the SDK on main and the one latest stable release, people tend to get confused. We probably don't want to point to a versioned branch from here as that will quickly become stale, but we may somehow want to indicate in the README of the SDK repos how to find examples for the latest stable version.

[dicej]

Perhaps we could create a stable branch in each of the SDK repos which always points to the latest stable release tag, and make updating it part of the release process for each SDK. Then we could link to those branches from here.

[vdice]

Double-checking with @itowlson on the subject of templates:

For go, Assuming the v3 version of the sdk in its new home is a ways out and there may be a handful of subsequent Spin releases (eg 2.3, 2.4, etc) before it is ready, do we need to do anything ensure templates function as expected? For as long as the go templates are in this repo and no new templates tags are pushed, will future spin clients just get the last, most recent templates (2.2) for this interim period?

The rust templates meanwhile should be ready to move to their new sdk home, right? Would we update the spin templates cli commands to add the new sdk repo as a default to fetch from?

(Or maybe the go templates are also ready to migrate to their new sdk home as well -- especially if spin clients just fetch the 2.2-tagged templates near-term?)

[itowlson]

If template tags are not updated, then post-2.2 Spin releases will fall forward to the templates on main.

Moving the templates has implications for the installer, docs, and spin new. I am wary of moving those without careful coordination.

[dicej]

OK, let's assume we won't move the templates for the foreseeable future. In that case, I guess our release process could look something like this:

• SDKs are released on their own schedule; for example, let's say we release spin-rust-sdk 3.0.0 tomorrow
• Templates remain tied to Spin releases, so they are not updated until the next Spin release; e.g. Spin 2.3 would be our first opportunity to update the Rust templates to use spin-rust-sdk 3.0.0 (although I guess we could update them in main sooner than that)
  • i.e. when we make a Spin release, we tag the templates as usual, and those templates will point to whatever the latest stable versions of the SDKs happen to be

Does that sound right? (No strong opinions here -- just trying to form a plan of some kind)

[itowlson]

We have to tag templates at minimum when we do a (non-patch) Spin release.

We can optionally update the templates and move the tags when we do a SDK release, even if no Spin release is planned. But that's not part of the Spin release process and can be ad-hocked in if we ever feel the urge to actually do it.

[vdice]

i.e. when we make a Spin release, we tag the templates as usual, and those templates will point to whatever the latest stable versions of the SDKs happen to be

That sounds reasonable to me. So, we'd re-introduce the corresponding automation around pushing the templates tag (eg spin/templates/v2.3) on a Spin release for the near-term? edit: as @itowlson says above, didn't yet see that comment when I posted this.

[dicej]

Er, maybe just keep push-templates-tag and remove create-template-sdk-update-pr, since we don't want to update SDK versions automatically.

[dicej]

e.g.:

  push-templates-tag:
    runs-on: ubuntu-latest
    needs: build-and-sign
    if: startsWith(github.ref, 'refs/tags/v')
    steps:
      - uses: actions/checkout@v3

      - name: Set the tag to spin/templates/v*
        shell: bash
        run: |
          spin_tag=$(echo "${{ github.ref }}" | grep -Eo "refs/tags/v[0-9.]+")
          IFS=. read -r major minor patch <<< "${spin_tag}"
          echo "TEMPLATE_TAG=spin/templates/$major.$minor" >> $GITHUB_ENV

      - name: Tag spin/templates/v* and push it
        shell: bash
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          git tag ${{ env.TEMPLATE_TAG }} -f
          git push origin ${{ env.TEMPLATE_TAG }} -f

[dicej]

I believe I've addressed this in 65ed372, but not sure how to test it. Maybe push a release tag to my fork?

[dicej]

Looks like it worked: https://github.com/dicej/spin/actions/runs/7995470091/job/21835889372

[vdice]

Yes, that should be it... thanks for testing!