feat/add package prereleases #1399
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
tk-o
left a comment
tk-o
left a comment
There was a problem hiding this comment.
Looks awesome to me 🚀 I suggested some minor changes, feel free to merge the PR once ready.
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@stevedylandev Thanks, excited for this! Shared some questions and requests for advice 👍
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
Co-authored-by: lightwalker.eth <126201998+lightwalker-eth@users.noreply.github.com> Co-authored-by: Tomek Kopacki <tomasz@kopacki.net>
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@stevedylandev Thanks for updates. Reviewed and shared feedback.
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
| 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 |
There was a problem hiding this comment.
@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. |
There was a problem hiding this comment.
Please see my comment below. I'm concerned about how we're currently describing use of the next tag. Advice appreciated.
|
|
||
| ## Choosing the Right Release Type | ||
|
|
||
| ### For Production Use: `@latest` (Full Releases) |
There was a problem hiding this comment.
@stevedylandev We should also make a high-visibility callout in our releases docs for how ENSNode is not currently using Semantic Versioning and therefore even patch or minor releases may include breaking changes.
| **When to use:** | ||
| - Production deployments and any critical infrastructure | ||
| - When you need maximum stability and control over updates | ||
| Pinned full releases are recommended for those who want to start using ENSNode artifacts. By using a pinned version you can maintain full control over features or patches that might be included. Review the release notes on the [Releases Page](https://github.com/namehash/ensnode/releases) to help decide which version to install. |
There was a problem hiding this comment.
Thanks @shrugs The above is all good.
@stevedylandev There's another important idea here that I would like to see explicitly included in our docs on this topic.
Specifically:
Each ENSIndexer version update is likely to produce an updated Ponder Build Id. Therefore, when updating your ENSIndexer version, ENSIndexer will likely refuse to start because its configured DATABASE_SCHEMA will be associated with an incompatible Ponder Build Id associated with the old ENSIndexer version.
Therefore, whenever updating your ENSIndexer version you should expect to also update the DATABASE_SCHEMA environment variable to point to a completely new Postgres Database Schema, such that a complete reindexing is performed for the new Ponder Build Id.
You can learn more about these Ponder mechanics in the Ponder docs: https://ponder.sh/docs/api-reference/ponder/database
A complete reindexing may take over 24 hours to complete depending on your ENSNode configuration and many factors. Therefore:
- ENSNode version updates require special coordination and should not be assumed to be a simple version bump.
- All use of ENSNode artifacts should always be pinned to specific version numbers so that you maintain control over the timing of your version upgrades.
| - 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). |
There was a problem hiding this comment.
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>
This PR closes #1359 by adding the following:
snapshot-release.yml- Automatically publishes@nextpackages and docker images for commits to mainpreview-release.yml- A manual workflow that can be run to create@previewpackages for a branch, helpful for testing a PR before merging tomainpackage.jsonto support scripting in new workflowsensnode.io/docs/contributing/releaseswith new flow