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 <[email protected]> Co-authored-by: Tomek Kopacki <[email protected]>
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@stevedylandev Thanks for the updates. One more key remaining issue. Please take the lead to merge when ready 👍
|
|
||
| ## Choosing the Right Release Type | ||
|
|
||
| ### For Production Use: `@latest` (Full Releases) |
There was a problem hiding this comment.
We'll need to be very careful here. I think it will be a big issue for people if we suggest they setup their deployments of ENSNode to always install @latest. This will cause all kinds of chaos and pain. Please ask if you have any questions about why.
We need to explain with precision here the distinction between using docker images that were made as a full release vs pinning your deployments of docker images to the @latest tag.
We need to explain (specifically!) why pinning your docker image deployments using the @latest tag will cause problems and is highly not recommended.
We need to explain the process someone should go through to decide which specific version number tag they should use for their docker image deployments.
Please ask in Slack and bring others from the team into the discussion on this. I believe it will be important to get input from @tk-o or @shrugs on this who have a lot of experience now with the nuances of ENSNode deployments and how this works with DATABASE_SCHEMA values, etc.
There was a problem hiding this comment.
yeah we should encourage people to use a specific version not the latest tag itself — we're not abiding by real semver so minors can have breaking changes. if it's trivial, it might even be best to remove the latest tag entirely, to avoid anyone doing that?
|
|
||
| - Check the GitHub releases page for the latest stable version and release notes | ||
| - Pin specific versions in your integrations rather than using tags like `@latest` | ||
| - Use full releases (`@latest`) as much as possible for stability |
There was a problem hiding this comment.
I see this bullet and the one above. They touch on the idea in my new comment up above but they do not sufficiently bring attention to this key issue.
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@stevedylandev Sharing feedback on the latest changes.
| npm install @ensnode/package-name@latest | ||
| docker run ghcr.io/namehash/ensnode:latest | ||
| npm install @ensnode/package-name@1 | ||
| docker run ghcr.io/namehash/ensnode:1 |
There was a problem hiding this comment.
These example version numbers look a bit funny to me. Maybe better to give an example such as 1.0.0 and also to explicitly identify how the bash commands have example placholder version numbers and that the reader should follow (instructions) to decide version to actually install.
My worry includes people blindly copy/pasting whatever is written here.
| **When to use:** | ||
| - When you need maximum stability and reliability | ||
| - When you want thoroughly tested features | ||
| - Production deployments and any critical infrastructure |
There was a problem hiding this comment.
"... and any critical infrastructure"
What does this mean? How is it distinct from "Production deployments"?
| - When you need maximum stability and reliability | ||
| - When you want thoroughly tested features | ||
| - Production deployments and any critical infrastructure | ||
| - When you need maximum stability and control over updates |
There was a problem hiding this comment.
What is the goal for writing this? I find this confusing and unclear.
| - The version will never change - you control when to upgrade | ||
| - No unexpected breaking changes or behavior changes | ||
|
|
||
| **Important:** 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 believe we have a way to create some kind of a special "callout" box in these .mdx files?
| - Stable, well-tested releases | ||
| - Complete release notes and changelog entries | ||
| - Stable, well-tested releases with complete release notes | ||
| - The version will never change - you control when to upgrade |
There was a problem hiding this comment.
This is confusing and unclear. It should be written better.
| **What to expect:** | ||
| - Stable, well-tested releases | ||
| - Complete release notes and changelog entries | ||
| - Stable, well-tested releases with complete release notes |
There was a problem hiding this comment.
We aren't performing strong enough testing yet for us to fairly claim "well-tested releases" yet.
We shouldn't write things that sound nice if they are not true.
| - The version will never change - you control when to upgrade | ||
| - No unexpected breaking changes or behavior changes | ||
|
|
||
| **Important:** 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.
Can we just completely remove any use of the latest tag on all the Docker images we publish (current and future)?
Note that use of the latest tag is a key issue with Docker images. It's not as big of an issue for NPM packages.
| - Pin specific versions in your integrations rather than using tags like `@latest` | ||
| - Use full releases (`@latest`) as much as possible for stability | ||
| - Only use snapshot releases (`@next`) for experimenting with new features | ||
| - **Always pin Docker deployments to specific version numbers** (e.g., `1.2.3`) - never use `latest` or omit the tag |
There was a problem hiding this comment.
This idea should be moved into the related section. Why are you expecting the reader to read the full page? This reflects not giving proper consideration to human behavior.
There was a problem hiding this comment.
I was originally following the patterns from this comment but you're right, there is probably a better way to make this more succinct.
| - Use full releases (`@latest`) as much as possible for stability | ||
| - Only use snapshot releases (`@next`) for experimenting with new features | ||
| - **Always pin Docker deployments to specific version numbers** (e.g., `1.2.3`) - never use `latest` or omit the tag | ||
| - Check the [GitHub releases page](https://github.com/namehash/ensnode/releases) to find the specific version number you need |
There was a problem hiding this comment.
This is a good idea, but it's in the wrong place.
docs/ensnode.io/src/content/docs/docs/contributing/releases.mdx
Outdated
Show resolved
Hide resolved
…ases.mdx Co-authored-by: lightwalker.eth <[email protected]>
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