chore: update beta release workflow to use snapshots #5365

rubencarvalho · 2025-04-10T20:12:02Z

Description

This PR updates the beta release workflow to use the snapshot approach for generating unique versions.

We had previously planned to have incremental suffixes for the beta releases (e.g.: 1.5.0-beta.0, 1.5.0-beta.1, etc.). But this was not working because in CI we do not persist the latest published version, so we would always try to publish beta.0. In this PR, we now use a snapshot approach that adds unique timestamps instead (e.g. 1.5.0-beta.20250411081626) ensuring there are no conflicts! :)

Motivation and context

The beta release workflow was previously not working correctly after the initial run due to version conflicts (you can see an example run).

The CI environment does not maintain state between runs (it does not know which beta version was last published), so it would always try to publish the same beta version (e.g., 1.5.0-beta.0):

The workflow now uses yarn changeset version --snapshot beta which together with a new changeset config, uses the calculated version and format the version to our desired version output. And by appending a unique timestamp-based suffix, we ensure each CI build creates a distinct version number that won't create conflicts.

How has this been tested?

Test locally
1. Pull this PR
2. run yarn changeset version --snapshot beta
3. expect to see the new version format in the package.json of any of the components (e.g. "version": "1.5.0-beta.20250411081626")

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

I have signed the Adobe Open Source CLA.
My code follows the code style of this project.
If my change required a change to the documentation, I have updated the documentation in this pull request.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.
I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.

changeset-bot · 2025-04-10T20:12:06Z

⚠️ No Changeset found

Latest commit: 475ec04

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

github-actions · 2025-04-10T20:14:08Z

Branch preview

Review the following VRT differences

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.

github-actions · 2025-04-10T20:17:00Z

Tachometer results

Currently, no packages are changed by this PR...

rubencarvalho · 2025-04-11T08:40:11Z

.changeset/config.json

-    "ignore": []
+    "ignore": [],
+    "snapshot": {
+        "useCalculatedVersion": true,


When changesets version --snapshot is used, the default behavior is to use 0.0.0 as the base version for the snapshot release.

Setting useCalculatedVersion: true will change the default behavior and will use the calculated version, based on the changeset files.

rubencarvalho · 2025-04-11T08:42:46Z

.changeset/config.json

+    "ignore": [],
+    "snapshot": {
+        "useCalculatedVersion": true,
+        "prereleaseTemplate": "{tag}.{datetime}"


This configures the suffix for the snapshot releases, using a template with placeholders.
I decided for tag.datetime, which seems to be a common pattern. But we could have used:

{tag} - the name of the snapshot tag, as specified in --snapshot something

{commit} - the Git commit ID

{timestamp} - Unix timestamp of the time of the release

{datetime} - date and time of the release (14 characters, for example, 20211213000730)

Note: because we are using {tag} as placeholder, we can't call --snapshot with an empty tag name - this will result in error.

What's nice too is I think the tag.datetime syntax matches how Garth did the snapshots for foundations in the spectrum-tokens repo too! Cross-team synchronicity!

@rubencarvalho what do you think about the tag being the PR number or the number is prepended the custom tag?This would make it easier to understand which beta snapshots are associated with PR fixes.

@caseyisonit There's no asset for PR number because there's no guarantee every tag will be connected to a PR but could use the commit.

I also looked into using the commit as a version suffix, but for some reason Changesets decided it should use the full commit hash, which results in a version like: 1.5.0-beta.29d804a8a923bba8c3beaec63fab76b856697b39.
Maybe we could contribute to Changesets to support a shortCommit option? 😛

Rajdeepc

LGTM! Thanks for bringing this in!

castastrophe · 2025-04-11T15:18:34Z

.github/workflows/beta-release.yml

              env:
                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
              run: |
-                  yarn changeset pre enter beta


When do you activate the beta mode state if you don't do it here? I didn't see this being done elsewhere -- or is it wrapped in a command now?

@rubencarvalho +1 on needing more clarity here

@castastrophe through my pairing with piyush on his other PR I now have a bit more context on this that I'm happy to share.

So essentially Rubens PR is suggesting using snapshot releases as a work around to the beta releases since running beta releases against main is warned against by changesets and we don't use a backup branch.

Warning: If you decide to do prereleases from the main branch of your repository, without having a branch for your last stable release without the prerelease changes, you will block other changes until you are ready to exit prerelease mode. We thoroughly recommend only running prereleases from a branch other than the main branch.

The other issue we were having is that beta releases weren't counting correctly due to leaving prerelease when it is merged. the pre.json doesn't persist so it wont override the latest version in the package.json.

I think this is a good temporary solution for providing releases to consumers to confirm the changes work.

Hopefully this helps make more sense out of what is being suggested.

Hey! This is a great question — I should’ve added a clarifying comment here. There are 3 main reasons:

We do not keep a living beta branch nor do we sync the newly generated beta version back to any other branch for that matter. As a result, when this workflow runs, it always calculates the same first version, e.g.: 1.5.0-beta.0

By not using the prerelease mode and instead using snapshots, we can generate a unique identifier (timestamp-based), which avoids the issue 1. without the overhead of managing a dedicated branch or modifying our existing workflows (that said, I do think there’s value in exploring a beta branch strategy or something along those lines in the future.)

There is a somewhat scary warning on the changesets documentation about using prerelease mode in main:

blunteshwar

I have made some changes to the beta release process so that we can leverage the current functionality and the version number will also look like this 1.5.0-beta.0 1.5.0-beta.1, 1.5.0-beta.2, and so on..
#5366

chore: update beta release workflow to use snapshots

128fcdd

rubencarvalho and others added 3 commits April 11, 2025 10:11

chore: add prereleaseTemplate

e4473d9

chore: use datetime instead

f5d3db1

Merge branch 'main' into ruben/beta-snapshot-releases

15949f2

rubencarvalho marked this pull request as ready for review April 11, 2025 08:31

rubencarvalho requested a review from a team as a code owner April 11, 2025 08:31

rubencarvalho commented Apr 11, 2025

View reviewed changes

chore: fix snapshot publish command

29d804a

rubencarvalho added Tooling ready-for-review labels Apr 11, 2025

Rajdeepc approved these changes Apr 11, 2025

View reviewed changes

castastrophe reviewed Apr 11, 2025

View reviewed changes

blunteshwar requested changes Apr 11, 2025

View reviewed changes

Merge branch 'main' into ruben/beta-snapshot-releases

ef7df92

blunteshwar self-requested a review April 11, 2025 17:43

blunteshwar approved these changes Apr 11, 2025

View reviewed changes

blunteshwar and others added 2 commits April 17, 2025 13:27

Merge branch 'main' into ruben/beta-snapshot-releases

b088c6f

Merge branch 'main' into ruben/beta-snapshot-releases

475ec04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore: update beta release workflow to use snapshots #5365

chore: update beta release workflow to use snapshots #5365

rubencarvalho commented Apr 10, 2025 •

edited

Loading

changeset-bot bot commented Apr 10, 2025 •

edited

Loading

github-actions bot commented Apr 10, 2025

github-actions bot commented Apr 10, 2025

rubencarvalho Apr 11, 2025

rubencarvalho Apr 11, 2025

castastrophe Apr 11, 2025

caseyisonit Apr 11, 2025

castastrophe Apr 11, 2025

rubencarvalho Apr 11, 2025

Rajdeepc left a comment

castastrophe Apr 11, 2025

caseyisonit Apr 11, 2025

caseyisonit Apr 11, 2025

rubencarvalho Apr 11, 2025 •

edited

Loading

blunteshwar left a comment

chore: update beta release workflow to use snapshots #5365

Are you sure you want to change the base?

chore: update beta release workflow to use snapshots #5365

Conversation

rubencarvalho commented Apr 10, 2025 • edited Loading

Description

Motivation and context

How has this been tested?

Types of changes

Checklist

Best practices

changeset-bot bot commented Apr 10, 2025 • edited Loading

⚠️ No Changeset found

github-actions bot commented Apr 10, 2025

Branch preview

Review the following VRT differences

github-actions bot commented Apr 10, 2025

Tachometer results

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Rajdeepc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rubencarvalho Apr 11, 2025 • edited Loading

Choose a reason for hiding this comment

blunteshwar left a comment

Choose a reason for hiding this comment

rubencarvalho commented Apr 10, 2025 •

edited

Loading

changeset-bot bot commented Apr 10, 2025 •

edited

Loading

rubencarvalho Apr 11, 2025 •

edited

Loading