Implement a release strategy

[gimenete]

So far I've been doing npm publish manually, but we should automate that.

[fabien0102]

https://github.com/google-github-actions/release-please-action

For ref, this is what I'm usually using for this kind of problem

[SferaDev]

@fabien0102 I very much enjoyed how the GitHub primer team does it.

In every PR you create a changeset file (markdown with frontmatter) where you set the description of the change for the release notes and the type to know how to bump the version number (ie: patch, minor, major). A bot helps you to create that file.

When the PRs are merged a bot is keeping track of them and opening another PR for Release Tracking. In the moment you merge it, the changeset files are removed, the version is bumped following semver according to the changes included, the changelog file is updated, the version is pushed to npm and the release is tagged on GitHub.

What do you think of that approach?

Example: primer/react#1894

In any case, we can implement the complex solution in the future and right now add a simple workflow_dispatch manual action that runs npm publish.

Also, do we want to release together all the packages (same version)?

[TejasQ]

Given that #19 is merged and we have automatic canary publishes and a manual workflow, is this closeable? Or is there more to be done here?

[gimenete]

I think we can close it.

@SferaDev WDYT?

[SferaDev]

I would like to have a more concise release strategy when actual users begin using the library.

For example, a bot that keeps track of the changes and decides which semver bump is needed and prepares the release notes.

Maybe we can keep this open as a low priority task but that needs to be implemented before public beta?

[gimenete]

Sounds good 👍

[SferaDev]

Yesterday @fabien0102 showed me his usage of release-please bot and is also a good alternative to my changesets proposal.

However for it to properly work we should enforce squash and merge and semantic names (aka feat, chore, etc...) in our PRs. If we decide not to enforce squash or semantic naming I can set the changesets alternative which is also quite easy to implement.

We're speedily approaching a point where I, personally, will be comfortable to begin onboarding a subset of our beta users to try the SDK. We're not there yet, but we should in a few weeks (main blockers right now: advanced usage of links, nested inference and adding support for PATCH operations).

Before that point we would need to begin documenting breaking changes and making sure we follow semver.

What do you all think?

[gimenete]

I've never used semantic commits such as feat, chore, etc. but I can learn. No strong opinions.

Agreed that having the ability to PATCH a record is a main blocker. I think that was close to be done in the backend, right? And agreed that also links (and objects!) is the other high priority.

Before that point we would need to begin documenting breaking changes and making sure we follow semver.

👍