README: update runtime-spec links to use main branch #1207
Conversation
ChengyuZhu6
commented
Oct 12, 2024
ChengyuZhu6
commented
- Updated several links in README.md, conversion.md, image-layout.md, and spec.md to point to the 'main' branch of the runtime-spec repository.
- Replaced outdated 'master' and 'v1.0.0' references with 'main' for consistency with the latest branch structure.
ChengyuZhu6
requested review from
jonjohnsonjr,
stevvooe,
sudo-bmitch,
sajayantony,
tianon and
cyphar
as code owners
There was a problem hiding this comment.
In general this LGTM with one minor nit. I think image-spec should consider whether we should bind these links to the current version of an external spec when we generate a release (similar to how we modify https://github.com/opencontainers/image-spec/blob/main/specs-go/version.go), but that's separate from this PR.
ChengyuZhu6
force-pushed
the
fix-branch
branch
from
aee9de9 to
ed8fe4b
Compare
Thank you for the review! I agree that the branch of the external spec should be updated during the release stage. |
|
I agree, but I disagree that doing so is separate from this PR; because we have these links currently pointing to a version, they're suitable to release as-is, and this PR changes that, so needs to come with some way to make sure we don't forget to update them back at release time. Because that's complicated to verify, my own preference for external specs would be that we continue to link to the latest release unless/until we can figure out a way to make that harder to forget and less error prone during release. (So, soft NACK from me for now. ❤️) |
|
I'd disagree that removing the current version pins is a bad thing. They are pointing to the same content from different parts of the spec, and none of those references to old versions appear to be for version specific content. My thought for how to adjust the release process is a script that does a find and replace for all of the "main" references, replacing them with the current tag of the external spec, and after the release commit is made, reverting those changes for the next dev commit. That would allow any permanent version pins to persist through the release process. So for me, having everything say "main" in our dev branch would be helpful. |
- Updated several links in README.md, conversion.md, image-layout.md, and spec.md to point to the 'main' branch of the runtime-spec repository. - Replaced outdated 'master' and 'v1.0.0' references with 'main' for consistency with the latest branch structure. Signed-off-by: ChengyuZhu6 <[email protected]>
|
I agree with all that, but I think those things should come together (the
swap to main and the script/process updates).
|
ChengyuZhu6
force-pushed
the
fix-branch
branch
from
ed8fe4b to
76b8bae
Compare
@tianon Thanks for the comments. I understand your point. While I think these are two tasks and should be handled in separate PRs to better manage the branch version of the external link.
WDYT? |
|
Without automation or process changes, I'm concerned about our ability to
remember to do the latter half, which is why I think unless or until we
address that somehow, the best we can or should do is link to the latest
release or even the latest revision explicitly if we want something
newer/unreleased.
|
|
@ChengyuZhu6 thanks for fixing the linter error, I think you've done everything needed for this PR. @tianon that's certainly a bad habit of ours. I'll see how fast I can put together a script, raise that as a separate PR, and then we can merge both. |
|
That wasn't too bad. #1208 has been opened with a script and release instructions to pin our references on a release. |
|
Ok, I'm convinced now; pending #1208, this looks good to me (but I do think we have to do them together) ❤️ |
