bip versioning #1675
pull RandyMcMillan wants to merge 2 commits into bitcoin:master from bitcoincore-dev:1999/864206/541012/758dfc9/9f58824-bip-0085-versioning changing 4 files +875 −363-
RandyMcMillan commented at 1:18 am on October 5, 2024: contributor
-
bip-0085@v2
* Add new maintainer (author unreachable) * Swap chain code and private key bytes in application 32' for consistentcy with BIP-32 (major change) * Correct derived entropy for application 128169' test vector (major change) * Clarify big endian serialization * Add the Portuguese language (9') to application 39' * Add dice application 89101' * Clarify Testnet support for XPRV application 32' * Minor grammar, format, clarity improvements
-
bip-0085.mediawiki:versioning
We preserve the original bip-0085 proposal as bip-0085/bip-0085@v1.mediawiki and add the bip-0085/bip-0085@v2.mediawiki revision
-
RandyMcMillan commented at 1:20 am on October 5, 2024: contributor
A way to structure major changes to BIPs while preserving original commit content for easy reference.
The bip-0085.mediawiki file includes commit hash and message, enabling developers to use a
git show
orgit checkout
to access the original commit. -
jonatack commented at 2:10 pm on October 5, 2024: member
This proposal would appear to require an update to the process. According to BIP 2: “It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.”
BIP85 will also be updated to Final status, given its adoption.
-
jonatack commented at 2:14 pm on October 5, 2024: member
Therefore, if a separate version is truly needed alongside an existing one, it should probably be a separate BIP.
For instance, BIP 78 (Payjoin) and future BIP 77 (Payjoin v2).
-
RandyMcMillan commented at 4:57 pm on October 5, 2024: contributor
With all that said…
I think you are missing the point…
How to handle and document a BIP that may have been originally implemented/deployed with a bug?
Simply amending the BIP proposal and burying the original flawed implementation isn’t enough - at a minimum - a Change log that explicitly references the original flawed specification should be easily referenced.
We also know forced pushes do happen!
I repeat!
We also know forced pushes do happen! Which could clobber the referenced original commit!
So preserving the original proposal verbatim is critical.
This is why a structure like this may be a way forward.
-
RandyMcMillan renamed this:
bip-0085 versioning
bip versioning
on Oct 5, 2024 -
RandyMcMillan commented at 5:21 pm on October 5, 2024: contributorNote: We have plenty of bips that use external links to reference implementations that get clobbered or go stale for some other reason - this should be avoided.
-
jonatack commented at 5:31 pm on October 5, 2024: member
Yes, I’m in favor of changelogs, and the current process update proposal at https://github.com/murchandamus/bips/pull/2 adds them.
We have plenty of bips that use external links to reference implementations that get clobbered or go stale
Please don’t hesitate to open a pull to update or remove stale links.
-
RandyMcMillan closed this on Oct 6, 2024
This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-06 22:10 UTC
More mirrored repositories can be found on mirror.b10c.me