Changesets

As a way of making the versioning of our libraries and apps easier in the context of a mono repository we use changesets for managing releases.

Changesets is a tool that enables an automatic tracking of versions, is able to handle multiple packages in a mono repository architecture, publish them and also supports pre-releases pretty well.

Here is how it works.

Changeset

You can refer to the CONTRIBUTING.md guidelines for more detailed explanations on how to work with the mono repo. This document will focus on the changesets part.

Definition

Changesets are designed to make your workflows easier, by allowing the person making contributions to make key decisions when they are making their contribution.

Changesets hold two key bits of information: a version type (following semver), and change information to be added to a changelog.

In order to have your PR merged you will need to attach one or more changeset to your contribution (99% of the time).

How to

To ship a changeset with a PR, it’s quite easy, you just need to run:

pnpm changelog

This will display a list of all known packages in the mono repository:

From there you will be able to select all packages affected by the code change.

Once you are done choosing which packages have been affected, you can choose the type of bump you want for each selected package.

Note: the Ledger Live packages follow the semver convention.

On the last step, you will need to enter a summary for our change. If possible add the context to this message (eg: github issue number) as well as an explicit description of what the changes bring.

For Ledger Employees: please add the Jira ticket number in the changeset if relevant.

This will allow us to have a better understanding of what has been done and what has been merged in our code base.

---

⚠️ Note: When a PR modifies apps (apps/*) and packages (libs/*) at the same time, changesets files must be split between apps and packages

Examples:

• A PR updates ledger-live-desktop and ledger-live-common: 2 changesets should be generated (1 for ledger-live-desktop, 1 for ledger-live-common)
• A PR updates ledger-live-desktop, ledger-live-mobile, ledgerjs and ledger-live-common: 3 changesets should be generated (1 for ledger-live-desktop, 1 for ledger-live-mobile and 1 for ledgerjs and ledger-live-common)

Why do we need to do that:

Basically changesets are used to bump versions of the published apps and packages. If the same changeset bump LLD and LLM, when doing the release process, we might inadvertently bump an application version (for example LLD) when we are doing the deployment of LLM for example. Resulting in a versioning chaos and potentially bypassing one version when we later do the release of the other app (LLM in this little example). This is why we can't have ledger-live-desktop and ledger-live-mobile in the same changeset file.

Furthermore, when doing the prerelease step, changesets are filtered for the specific app we are deploying (ledger-live-desktop or ledger-live-mobile). This is why we can't have an app (ledger-live-desktop for example) mixed with a package (ledger-live-common for example). Otherwise, we might encounter a Found mixed changeset error when versioning for a specific app.

cf. https://github.com/LedgerHQ/ledger-live/blob/main/.github/workflows/release-prerelease.yml#L76-L87

---

Note: When a PR does not contain any changeset, a custom github action will comment on the PR to ensure that this is not an oversight.

Changesets are actually markdown files that are created in the .changeset/ folder.

After merge

Let us assume that a PR has been created and a changelog has been added to it. If it passes CI and has been reviewed by devs + QA (again, refer to CONTRIBUTING.MD) then it should be ready to merge.

Changesets will keep getting accumulated in the develop branch until the release day, at which point they will be consumed and CHANGELOG.md files will get populated.