Automate Release Cycles (Implement Changesets or other relevant solution)

[jasonbahl]

As a WPGraphQL plugin contributor, I want to create a release workflow that leverages changesets in order to assist with scheduling releases and mitigate human error.

Acceptance Criteria

Changesets is implemented in the following repos:

Technical Details

• Prior Art - https://github.com/wpengine/wp-graphql-content-blocks
• Changesets - https://github.com/changesets/changesets
• Original Jira ticket for adding changesets to wp-graphql-content-blocks - https://wpengine.atlassian.net/browse/MERL-746

[justlevine]

Related: #3003

I strongly recommend leaning into Conventional Commits for docs/versioning instead of something like Changesets that imo adds more friction than value

[jasonbahl]

@josephfusco and I discussed this a bit further.

We see a path forward where we can leverage changesets to reduce some manual maintainer work for releases, without increasing the burden on contributors.

My idea is that we can leverage our existing lint-pr workflow that enforces "Conventional Pull Request" titles and automate changeset commits from that.

If a PR is opened with a valid Conventional PR, then either a changeset commit is added to the PR itself or a Changeset commit is added at the time the PR is merged (this is likely the least impact on a contributor and maintainer's existing workflows).

I see the workflow as something like:

• Contributor opens PR
• Lint-PR workflow runs
• Contributor (or maintainer) fixes PR title if the title is invalid
• PR is reviewed as normal
• PR is merged
• Workflow runs upon merge automatically adding a changeset commit to the develop branch using the Conventional PR title to describe what changed for the changeset.
• Releases use whatever other Changeset automation to gather all changesets, update changelog, update version numbers, update @since @todo tags, etc.

I think this could lead to a "best of both worlds" where maintenance burden is reduced and contributors don't have to have any burden passed to them. 🤷🏻‍♂️

We plan to explore some workflows in the wpgraphql-ide repo to see if we can come up with some patterns/workflows that improve maintainer efficiency but do not increase contributor complexity/effort.

[justlevine]

I think this could lead to a "best of both worlds" where maintenance burden is reduced and contributors don't have to have any burden passed to them. 🤷🏻‍♂️

Perhaps it help me if I understand what exactly the best from "world" of changesets is supposed to be.

From the above flow it doesn't actually seem like we need changesets either. Further, creating changesets as a separate commit means the changelogs generated are likely to be pointless or partial and unhelpful. (Hopefully there's a way to solve this with Changeset's config, but again why bother when Conventional Commits is already a SemVer implementation)

The workflow can be simplified sans-changesets as:

* Contributor opens PR
* Lint-PR workflow runs
* Contributor (or maintainer) fixes PR title if the title is invalid.
* PR is reviewed as normal
* PR is merged
- * Workflow runs upon merge automatically adding a changeset commit to the develop branch using the Conventional PR title to describe what changed for the changeset.
- * Releases use whatever other Changeset automation to gather all changesets, update changelog, update version numbers, update @since @todo tags, etc.
+ * Releases use Conventional Commits prefixes to update changelog, update the since/todo tags etc.

I'm gonna hold off on any other feedback until I see something reviewable in graphql-ide, the above is for your consideration while experimenting with patterns.

[jasonbahl]

Ya the outcome might even be not using changesets 🤷‍♂️

I think we made a mistake of suggesting a solution too early.

The problem is:

How do we reduce some of manual labor and human mistakes involved in the current release process.

Changesets was suggested but may or may not prove to be the correct outcome.

[jasonbahl]

related: #3003