Version
field in the header with semver inspired syntax. This PR allows the inclusion of this field and checks that it matches the <MAJOR.MINOR.PATCH>
format.
Version
field in checks as per BIP 3
#1891
Version
field in the header with semver inspired syntax. This PR allows the inclusion of this field and checks that it matches the <MAJOR.MINOR.PATCH>
format.
Thanks, this looks great!
There is just the hitch that BIP 3 is “Proposed”, but not active yet. I’m working on a PR to suggest activation of BIP 3 in #1820. Seeing your PR, I had actually overlooked that I wasn’t adding the Version field to the buildtable script, so thanks for putting this together. I would propose to cherry-pick this commit into #1820, if that’s okay for you, because the Version field doesn’t exist in the BIP 2 process, and we will need to allow it when BIP 3 becomes active. Alternatively, we could merge your PR alongside #1820, when BIP 3 is activated.
Meanwhile it seems fine to me for BIP authors to use the Changelog section without putting the Version field in the preamble, and we can then backfill the version fields to the corresponding BIPs after BIP 3 activates.
I would propose to cherry-pick this commit into #1820, if that’s okay for you, because the Version field doesn’t exist in the BIP 2 process, and we will need to allow it when BIP 3 becomes active. Alternatively, we could merge your PR alongside #1820, when BIP 3 is activated.
Sure, I would prefer whatever minimizes hassle for BIP editors, so sounds like cherry-picking into 1820 and removing the version field from 1890 for now makes the most sense, but I defer to your judgement
Labels
Process