bip versioning#1675
Conversation
* 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
We preserve the original bip-0085 proposal as bip-0085/[email protected] and add the bip-0085/[email protected] revision
|
A way to structure major changes to BIPs while preserving original commit content The bip-0085.mediawiki file includes commit hash and message, |
|
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. |
|
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). |
|
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. |
|
Note: 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. |
|
Yes, I'm in favor of changelogs, and the current process update proposal at murchandamus#2 adds them.
Please don't hesitate to open a pull to update or remove stale links. |
3 participants
No description provided.