# tbDEX Release Checklist

The following will be an issue template to be requested whenever a tbDEX SDK maintainer wants to release their package(s), in the *developer.tbd.website repo* ([example here](https://github.com/TBD54566975/developer.tbd.website/issues/1033)).

To request the new release, go to the [developer.tbd.website repo issues](https://github.com/TBD54566975/developer.tbd.website/issues), click in New Issue and select New tbDEX SDK Release (to be created).

## [tbDEX Upgrade]: small_summarized_title_here

**Packages in the Release**

| Package | Preview/Snapshot | Next Release Version |
| ----------------------- | ---------------- | -------------------- |
| @web5/common (js) | snapshot_sha | vN.N.N |
| @web5/credentials (js) | snapshot_sha | vN.N.N |
| @web5/crypto (js) | snapshot_sha | vN.N.N |
| @web5/dids (js) | snapshot_sha | vN.N.N |
| @tbdex/http-client (js) | snapshot_sha | vN.N.N |
| @tbdex/http-server (js) | snapshot_sha | vN.N.N |
| @tbdex/protocol (js) | snapshot_sha | vN.N.N |
| web5-kt | snapshot_sha | vN.N.N |
| tbdex-kt | snapshot_sha | vN.N.N |
| web5-swift | snapshot_sha | vN.N.N |
| tbdex-swift | snapshot_sha | vN.N.N |

_TODO: Fill the packages information that you want to release above, remove the ones that you don't need to include in this release._

**Pre-Release Stage**

- [ ] (tbDEX SDK Team) Describe expected impact of this release.
- API Breaking Changes? (👍/👎)
- Breaking changes after v1 MUST bump major
- If not ready for major bump, consider adding new interfaces
- [ ] (tbDEX SDK Team) Make sure license and security checks are green.
- [ ] (tbDEX SDK Team) Cut the preview snapshot for acceptance testing.
- Swift: automated, just indicate the commit sha
- JS: automated, just indicate the commit sha
- Kotlin:
- (pre-maven) cut the SNAPSHOT version following the steps on readme and indicate the version here
- (post-maven) automated, just indicate the commit sha
- _Snapshot Version should be indicated in the GH Issue Thread below as a comment_
- [ ] Start a Discord Thread about this Release
- Discord Thread Link: https://discord.com/channels/XXXXXXX/XXXXXXX
- [ ] (OSP Team) Open PR on dev-website pointing to the preview snapshot
- PR: https://github.com/TBD54566975/developer.tbd.website/pull/NNNN
- [ ] (OSP Team) This will trigger a Deploy Preview on Netlify.
- Deploy Preview: https://deploy-preview-NNNN--tbd-website-developer.netlify.app/
- [ ] (OSP Team) Run the monorepo tests - this will cover code snippets and examples
- Tests Results link (MUST be ✅): https://github.com/TBD54566975/developer.tbd.website/actions/runs/NNNNNNN
- [ ] (DevRel) If errors, issue updates to guides, examples in the release branch until tests pass
- **Note to teams**: there may be a back and forth if DevRel discovers upstream issues that need to be addressed, with new Snapshots if so

**Final Release Stage**

- [ ] (tbDEX SDK Team) Cut the final release of the package next version
- [ ] (OSP Team) Update package final release version in the dev-website PR
- [ ] (OSP Team) Rebase, check tests and merge PR to `main`

---

(end of the GH Issue)

## Ideas

### 1. Packages Grouping

The above checklist could work for multiple packages being grouped in a single release or individual packages releases.

eg: swift + js + kotlin can be all released once vs going through this checklist for each separately.

**Which one should we prefer?**

### 2. Release Autonomy

As much as we want to give SDK Maintainers autonomy to bump whenever they want to, we need to be mindful about two things:
a. once the release is out it's out for the public, it's immutable; this might be ok for v0.X releases, but after v1 we should be more reliable.
b. the dev website guides should never be in a BROKEN state! But at the same time going through the entire steps above for a simple bump could discourage maintainers from releasing often.

**Solutions**

**Versions Lock**: With Swift and Kotlin we are ok because their package managers required versions lock; what if we rewrite our guides from `npm install <package>` which will always pull latest, to `npm install <package>@<locked-version>`. By doing this, maintainers can release as they wish (being mindful of item 2.a above) while DevRel can catchup and group versions bumps when they are ready to announce it. **The problem here becomes that our SDKs docs will be published as they are released! :(**

**Versioning the Devs Website Guides**: Could we adhere to these traditional dropdown menus in docs websites where we can pick the version? Something that is not clear is that each package has its own version. What does it mean to choose tbdex v1? v1.1? v1.2? We have swift, kotlin and js subpackages that don't share the same version...

### 3. Automations

What can be automated above?

A manual pre-release workflow could be dispatched from the source SDK repo which could trigger all of the above in a temporary branch of the dev website. Once everything is green this branch could be turned into a PR to be checked by DevRel (in terms of guides updates/announcements) and then the final release could be cut, with the PR being updated and merged.

Maybe this could be a discord bot integration... `/release tbdex` :thinking_face:

**More ideas?**

# Misc and Notes