Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Living EIP's MUST contain revision history or some versioning sub identifier #8308

Open
sambacha opened this issue Mar 12, 2024 · 3 comments

Comments

@sambacha
Copy link
Contributor

Proposed Change

Living EIP Revision History

Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.1

Since Living EIP's are permitted to be updated and are in a sense 'ephemeral', some revision/revset/versioning identifier should be made as an optional reference, e.g. EIP-1 03.2024 would refer to EIP-1, with the version being a calver value meaning March 2024.

This behaviour is already sort of implied within EIP-1, if we follow the spec we see the following passage:

Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard.2

This proposal is suggesting that some versioning be included, in regards to what versioning scheme should be left to the EIP Authors / Editors on a per-occurrence basis.

Footnotes

  1. https://eips.ethereum.org/EIPS/eip-1#:~:text=Living%20%2D%20A%20special%20status%20for%20EIPs%20that%20are%20designed%20to%20be%20continually%20updated%20and%20not%20reach%20a%20state%20of%20finality

  2. https://eips.ethereum.org/EIPS/eip-1#:~:text=Although%20not%20recommended,current%20living%20standard

@SamWilsn
Copy link
Contributor

Where would these references be used? It doesn't make much sense to link to an old EIP-1, since those rules aren't used any more.

@bumblefudge
Copy link
Contributor

Random prior art plugs:

  • DID WG has ?versionTime= for versions of a living document (i.e. a DID Document)
  • W3C-CCG (community group) incubated this IETF internet-draft "hashlink" spec, which gives a standard format for tacking ?hl={md5 hash of referent} onto a link to warn you if the link, at time of press, referred to a version that has changed (finding the right version out of scope)

Not sure either is what you're proposing, but just mentioning in case it helps. Mostly I'm just a big fan of query parameters.

@Mortiemi
Copy link

Proposed Change

Living EIP Revision History

Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.1

Since Living EIP's are permitted to be updated and are in a sense 'ephemeral', some revision/revset/versioning identifier should be made as an optional reference, e.g. EIP-1 03.2024 would refer to EIP-1, with the version being a calver value meaning March 2024.

This behaviour is already sort of implied within EIP-1, if we follow the spec we see the following passage:

Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard.2

This proposal is suggesting that some versioning be included, in regards to what versioning scheme should be left to the EIP Authors / Editors on a per-occurrence basis.

Footnotes

  1. https://eips.ethereum.org/EIPS/eip-1#:~:text=Living%20%2D%20A%20special%20status%20for%20EIPs%20that%20are%20designed%20to%20be%20continually%20updated%20and%20not%20reach%20a%20state%20of%20finality
  2. https://eips.ethereum.org/EIPS/eip-1#:~:text=Although%20not%20recommended,current%20living%20standard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants