Quest: update release process for independent versioning

[ef4]

Presently, all the packages in the embroider monorepo release together with one version number. But we have reached the point where that is problematic. It would be much better to pick between major, minor, or patch for each package that has changed since being released last, and not release unchanged packages at all.

The specific motivating use cases right now include:

• macros, util, and addon-shim are quite stable and doing unnecessary semver majors for these is quite disruptive because so many addons depend on them.
• addon-dev is evolving quickly and would benefit from semver majors. This is less disruptive because it's only an addon devDependency, not dependency.
• core and compat are due for a 2.0 that would let us drop support for older ember versions and simplify the codebase and options. I have held off so as not to make life hard for macros, util, addon-shim, etc.

Requirements:

• Make git tags per package. So instead of tagging "v1.18.2", we would need something like "v1.18.2-core", "v1.18.2-compat", etc. This is necessary once package version numbers are allowed to diverge, and it lets a user figure out what code really went into a given version of a given package. Many of these tags will point at the same commit, because many packages are still likely to be released together, and that is fine.
• Use the aforementioned git tags to determine whether a package has changed since its last release. For example:
  1. Read the version number in packages/core/package.json. Let's say it says "1.18.2".
  2. Use git to ask what files have changed between the v1.18.2-core tag and the current commit.
  3. If none, skip releasing core. Else, make sure we prompt the user to decide whether core should be a major, minor, or patch release, the same way release-it already prompts now for monorepo as a whole.
• We should keep the behavior that when one package is bumped to a new version number, the dependencies on it in the other packages should bump to match. These releases should all go out together, so that the release process is not very sensitive to what order the packages are released.
• Do something sensible with the changelog. Our current changelog generation is good and my suspicion is that it would support independent versioning just fine (since it uses lerna-changelog, and lerna supports independent versioning)
• Do something sensible with the release published on GitHub. Right now it's titled with the version number, but there won't be a single version number anymore.

I like release-it overall and I am open to contributing to (or forking and maintaining if there is delay) https://github.com/release-it-plugins/workspaces which has open issues discussing how to add most of this capability. See release-it-plugins/workspaces#40 and release-it-plugins/workspaces#36.

I am also open to adopting an entirely different tool (for example, lerna) if someone wants to figure out how to get it to do what we need.

A final alternative I will mention is that we could keep the same release setup but move some packages out of the monorepo. I'm open to discussing that, but the main work involved would be keeping our integrated test suite. We really want to know before releasing if changes to one package cause test suite failures in another.

[NullVoxPopuli]

Maybe an option: https://github.com/statelyai/xstate/tree/main/.changeset (still getting details):

• https://github.com/changesets/changesets

[NullVoxPopuli]

This is pretty cool,

I asked:

is there a good way to test out what Changesets would do without publishing?

Andarist answered

Changesets publish when there are no changeset files in your base branch - so be cautious when initing it because if you have some dirty state in your monorepo (package.json version bumped without a version being actually published) then it will publish that (because it syncs to the registry what has not yet been published but what’s available locally.

With a changesets action a versioning PR gets created and publish only happens when you land that
In that versioning PR u can review all the version bumps and stuff
You can also call changeset version locally to “apply” your local changeset files (bump versions, remove changeset files and update changelogs)
You wont verify locally github releases though.

---

So, I think what we want to do is setup the changeset action, add some changeset files, and make sure the PR it generates looks good -- once we merge it, it'll do the releasing for us

[NullVoxPopuli]

PR: #1259

[ef4]

This is reopened because changesets is pretty far from what I described in this issue. Having tried it, it's really not what I'm looking for. From a correctness perspective, the biggest gap is:

Use the aforementioned git tags to determine whether a package has changed since its last release.

I want a system that asks you to account for every code change as either major, minor, or patch and then guarantees those changes go out. With changesets, you don't get that guarantee unless you buy into their whole workflow, putting a required changeset into every PR (and locking down the possibility of any changes that don't go through PRs).

[NullVoxPopuli]

putting a required changeset into every PR

Can you expand on this? This is not required

and locking down the possibility of any changes that don't go through PRs

You mean you want these prevented? This would only affect those who have push-to-main access, yeah?

for every code change as either major, minor, or patch

You want to force this? Semantic-release does, but then forces a commit convention, and monorepo support is pretty rough, imo

[ef4]

Can you expand on this? This is not required

I'm saying that if you don't require it, changesets offers no other line of defense to guarantee that a change will get released.

You mean you want these prevented?

No, all I'm saying is that changesets doesn't read git to decide what needs to be released. It reads changeset files. And the tools they give you to make sure there are appropriate changeset files are all about controlling things during PRs.

You want to force this? Semantic-release does, but then forces a commit convention, and monorepo support is pretty rough, imo

I want to force this at the time of release. Not at the time you're making a commit.

[ef4]

What I'm asking for can be described very briefly: if a package has been changed since it was last released, when you're doing a new release the system needs to ask you if you want that change to major, minor, or patch.

Right now the system will just happily ignore that package, leaving your fix unreleased. There is no check to point out that you have code changes with no changeset file.

[NullVoxPopuli]

For a preview of changeset releasing multiple packages automatically:

• releases: https://github.com/CrowdStrike/ember-headless-form/releases
• tags: https://github.com/CrowdStrike/ember-headless-form/tags

This repo just did it's first releases, so (imo) it's easier to digest.
hope it's helpful