README: update runtime-spec links to use main branch

[ChengyuZhu6]

• 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.

[sudo-bmitch]

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]

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.

Thank you for the review! I agree that the branch of the external spec should be updated during the release stage.

[sudo-bmitch]

LGTM

[tianon]

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. ❤️)

[tianon]

(making my soft NACK explicit in GitHub's metadata)

[sudo-bmitch]

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.

[tianon]

I agree with all that, but I think those things should come together (the swap to main and the script/process updates).

[ChengyuZhu6]

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.

@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.

1. Current PR: keep the dev branches of external spec links in our dev branch.
2. Future PR: create a script (or similar way) to automatically update all external spec links to their latest release versions during the release process.

WDYT?

[tianon]

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.

[sudo-bmitch]

@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.

[sudo-bmitch]

That wasn't too bad. #1208 has been opened with a script and release instructions to pin our references on a release.

[tianon]

Ok, I'm convinced now; pending #1208, this looks good to me (but I do think we have to do them together) ❤️