Skip to content

Conversation

@stevedylandev
Copy link
Contributor

@stevedylandev stevedylandev commented Dec 12, 2025

This PR closes #1359 by adding the following:

  • snapshot-release.yml - Automatically publishes @next packages and docker images for commits to main
  • preview-release.yml - A manual workflow that can be run to create @preview packages for a branch, helpful for testing a PR before merging to main
  • Updates package.json to support scripting in new workflows
  • Updates docs at ensnode.io/docs/contributing/releases with new flow

@vercel
Copy link

vercel bot commented Dec 12, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
admin.ensnode.io Ready Ready Preview, Comment Jan 1, 2026 6:58pm
ensnode.io Ready Ready Preview, Comment Jan 1, 2026 6:58pm
ensrainbow.io Ready Ready Preview, Comment Jan 1, 2026 6:58pm

@changeset-bot
Copy link

changeset-bot bot commented Dec 12, 2025

⚠️ No Changeset found

Latest commit: 7e778f8

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

Copy link
Contributor

@tk-o tk-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks awesome to me 🚀 I suggested some minor changes, feel free to merge the PR once ready.

Copy link
Member

@lightwalker-eth lightwalker-eth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stevedylandev Thanks, excited for this! Shared some questions and requests for advice 👍

Co-authored-by: lightwalker.eth <126201998+lightwalker-eth@users.noreply.github.com>
Co-authored-by: Tomek Kopacki <tomasz@kopacki.net>
Copy link
Member

@lightwalker-eth lightwalker-eth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stevedylandev Thanks for updates. Reviewed and shared feedback.

npm install @ensnode/package-name@next
docker run ghcr.io/namehash/ensnode:next
npm install @ensnode/[package-name]@next
docker run ghcr.io/namehash/ensnode/[app-name]:next
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stevedylandev @shrugs @jarmint Appreciate your advice on this I'm not familiar with how Docker handles these things.

Goal: All installation instructions we share (including for snapshot releases) should never auto-upgrade themselves as we publish future iterations of releases. Our docs should instruct everyone building on any form of ENSNode artifacts to always fully pin all version numbers of their ENSNode dependencies such that they retain full and explicit control over if and when to consume any updated ENSNode artifacts.

### Snapshot Releases
:::caution
Never use the `latest` tag for Docker deployments (e.g., `ghcr.io/namehash/ensnode:latest` or `ghcr.io/namehash/ensnode`). The `latest` tag is a mutable pointer that will automatically pull different versions over time, causing unexpected updates and potential breaking changes in your deployment. Always pin to a specific version number from the [GitHub releases page](https://github.com/namehash/ensnode/releases).
The `next` tag is a floating pointer that always references the most recent snapshot release. When using Docker images with the `next` tag, you must run `docker pull` to update your local Docker cache if you want to get the actual latest image. Without pulling, you may continue using an older cached version.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see my comment below. I'm concerned about how we're currently describing use of the next tag. Advice appreciated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this :next tag seems redundant for me and just adds uncertainty.

the :latest tag has it's own use for POCs / Demos / development / test environments / CI builds for pulling cache faster. But as mentioned in already placed document: should never be used for running in production.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jarmint Let's move this discussion into Slack.

- The version will never change - you control when to upgrade
- No unexpected breaking changes or behavior changes
:::caution
Never use the `latest` tag for Docker deployments (e.g., `ghcr.io/namehash/ensnode:latest` or `ghcr.io/namehash/ensnode`). The `latest` tag is a mutable pointer that will automatically pull different versions over time, causing unexpected updates and potential breaking changes in your deployment. Always pin to a specific version number from the [GitHub releases page](https://github.com/namehash/ensnode/releases).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not so clear here right now. Specifically I'm confused about docs updates vs updates to how things actually work.

My understanding is that we have a goal to completely remove any use of the latest tag from our Docker images. Not only in our docs, but also that there's no longer any published artifacts tagged latest.

Is that true?

Assuming so, what remaining actions need to be taken for us to achieve this.

Please help me understand both the goal state, what state will be achieved when this PR is merged, and what additional follow-up actions if any are required after merging this PR to reach the goal state.

Co-authored-by: lightwalker.eth <126201998+lightwalker-eth@users.noreply.github.com>
Copy link
Member

@lightwalker-eth lightwalker-eth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All goals on this PR have been achieved with carve outs for a few separate follow-up issues:

  1. #1451
  2. #1452

@lightwalker-eth lightwalker-eth merged commit ce1540a into main Jan 2, 2026
12 checks passed
@lightwalker-eth lightwalker-eth deleted the feat/add-package-prereleases branch January 2, 2026 12:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add prerelease option to release workflows

6 participants