build: Drop the leading 0 from the version number #20223

pull achow101 wants to merge 1 commits into bitcoin:master from achow101:drop-leading-0 changing 17 files +37 −47
  1. achow101 commented at 6:23 pm on October 22, 2020: member

    Removes the leading 0 from the version number. The minor version, which we had been using as the major version, is now the major version. The revision, which we had been using as the minor version, is now the minor version. The revision number is dropped. The build number is promoted to being part of the version number. This also avoids issues where it was accidentally not included in the version number.

    The CLIENT_VERSION remains the same format as previous as previously, as the Major version was 0 so it never actually got included in it.

    The user agent string formatter is updated to follow this new versioning.

    Honestly I’m just tired of all of the people asking for “1.0” that maybe this’ll shut them up. Skip the whole 1.0 thing and go straight to version 22.0!

    Also, this means that the terminology we commonly use lines up with how the variables are named. So major versions are actually bumping the major version number, etc.

  2. laanwj commented at 6:40 pm on October 22, 2020: member
    Concept ACK
  3. practicalswift commented at 6:42 pm on October 22, 2020: contributor
    Concept ACK: a.) number go up is good, and b.) big number going up is obviously better than small number going up! :)
  4. DrahtBot added the label Build system on Oct 22, 2020
  5. DrahtBot added the label Docs on Oct 22, 2020
  6. DrahtBot added the label GUI on Oct 22, 2020
  7. achow101 force-pushed on Oct 22, 2020
  8. hebasto commented at 7:46 pm on October 22, 2020: member
    Concept ACK for 0.22.0 -> 22.0
  9. Emzy commented at 8:01 pm on October 22, 2020: contributor
    Concept ACK for 0.22.0 -> 22.0
  10. michaelfolkson commented at 8:48 pm on October 22, 2020: contributor

    Concept ACK

    Redundancy is generally worth considering but this 0.x redundancy seems unnecessary for all possible future scenarios. I’m assuming we don’t need to look as far ahead as v99, v100… :)

  11. luke-jr commented at 9:13 pm on October 22, 2020: member
    Concept NACK, we should stick to a standard versioning system. Either semver (0.features.bugfixes or features.0.bugfixes) or calendar versioning (yy.mm.bugfixes). Whatever we do, CLIENT_VERSION and the UA should reflect it properly. If we go with calendar versioning, replacing 0.21 with 20.11 would make a smoother migration than a 21.N following 0.21.
  12. fjahr commented at 9:53 pm on October 22, 2020: member
    Following the discussion in the meeting today I am somewhat indifferent towards making a change. I guess I just have not been asked about a 1.0 enough ;) But if we do change anything I strongly prefer this to all the other approaches that were discussed because it’s a simple change and simple to explain to outsiders.
  13. DrahtBot commented at 10:32 pm on October 22, 2020: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #18980 (build: Decouple clientversion.cpp from the git repo by hebasto)
    • #18261 (Erlay: bandwidth-efficient transaction relay protocol by naumenkogs)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  14. JeremyRubin commented at 11:07 pm on October 22, 2020: contributor

    I’d prefer if we track the calendar, e.g. 20.11 for a november 2020 release as luke suggests.

    But if it’s too late to make that happen I am happy to just drop the 0.

  15. MarcoFalke removed the label Docs on Oct 23, 2020
  16. MarcoFalke removed the label GUI on Oct 23, 2020
  17. MarcoFalke added this to the milestone 0.22.0 on Oct 23, 2020
  18. MarcoFalke removed this from the milestone 22.0 on Oct 23, 2020
  19. MarcoFalke added this to the milestone 22.0 on Oct 23, 2020
  20. MarcoFalke commented at 7:54 am on October 23, 2020: member

    Concept ACK

    Assigned 22.0 milestone

  21. jnewbery commented at 7:59 am on October 23, 2020: member

    Concept ACK

    This was discussed in yesterday’s meeting: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-22-18.59.log.html#l-122

    Current status (please correct me if I’m wrong and I’ll update):

    Concept ACKs (10): @achow101, @laanwj, @practicalswift, @hebasto, @emzy, @michaelfolkson, @JeremyRubin, @MarcoFalke, @jnewbery, @sipa Indifferent (2): @fjahr, @jonatack Concept NACK (1): @luke-jr

  22. kristapsk commented at 3:51 am on October 24, 2020: contributor
    I tend to agree with @luke-jr here.
  23. promag commented at 7:48 am on October 24, 2020: member

    Concept ACK. No strong opinion if it should be this release.

    It makes sense to me because versions like 0.19.0.1 wouldn’t exist.

  24. practicalswift commented at 8:40 am on October 24, 2020: contributor

    @kristapsk

    I tend to agree with @luke-jr here.

    Do you mean in the NACK sense (“don’t drop the leading zero”), or in the use calendar version sense (“20.11” would be November 2020)? :)

  25. luke-jr commented at 1:33 pm on October 24, 2020: member

    It makes sense to me because versions like 0.19.0.1 wouldn’t exist.

    0.19.0.1 is fundamentally different from typical bugfix releases, which are normally using the 3rd int.

  26. promag commented at 1:51 pm on October 24, 2020: member
    @luke-jr fundamentally different? At the time, if it was 19.0.0, we would just tag 19.0.1, or am I wrong?
  27. luke-jr commented at 2:42 pm on October 24, 2020: member
    @promag Anything is possible with such hypotheticals. If we had 19.0.0, we should never have 19.1.0 because we don’t do minor feature releases…
  28. luke-jr commented at 2:42 pm on October 24, 2020: member
    (Hmm, unless we decide softforks count as minor features?)
  29. theStack commented at 11:56 am on October 25, 2020: member
    Is there any strong fundamental long-term drawback on the calendar versioning, i.e. yy.mm.bugfixes (as suggested by JeremyRubin, luke-jr), other than “dropping the zero is simpler”? If not, I’d prefer the calendar versioning as well, it’s just nice that you can immediately deduce when a client/node has been last updated by looking at the version, w/o having to look up the version history.
  30. luke-jr commented at 1:56 pm on October 25, 2020: member
    @theStack Calendar versions don’t do that… 2020.11.5 may very well have been released in 2022 and up to date.
  31. theStack commented at 3:11 pm on October 25, 2020: member

    @theStack Calendar versions don’t do that… 2020.11.5 may very well have been released in 2022 and up to date.

    True, that doesn’t work with bugfix releases (obviously), but at least it gives a lower bound in the sense of “not older than”. I’d still not consider a node “up to date” if it has the latest bugfixes but is based on a years old feature set…

  32. achow101 commented at 4:30 pm on October 25, 2020: member

    Is there any strong fundamental long-term drawback on the calendar versioning, i.e. yy.mm.bugfixes (as suggested by JeremyRubin, luke-jr), other than “dropping the zero is simpler”? If not, I’d prefer the calendar versioning as well, it’s just nice that you can immediately deduce when a client/node has been last updated by looking at the version, w/o having to look up the version history.

    I think the main drawback is user confusion. Changing the version number to a new scheme will cause confusion in the short term, but in the long term, when referring to older releases, there may also be confusion there. I think that with this change, there will be less confusion. It’s easier to explain that the versioning is the same but just without the leading zero, than it is to explain that, e.g. 20.11 is the major release and there are no versions 20.0 - 20.10.

    In terms of code changes, both switching to calendar versioning and this change are probably the same amount of changes in roughly the same places. It’s just that conceptually it’s easier to understand “drop the unused zero” than it is to understand switching to something entirely new.

  33. kristapsk commented at 10:25 pm on October 26, 2020: contributor

    @kristapsk

    I tend to agree with @luke-jr here.

    Do you mean in the NACK sense (“don’t drop the leading zero”), or in the use calendar version sense (“20.11” would be November 2020)? :)

    NACK. I don’t see a problem with leading zero.

  34. sipa commented at 10:30 pm on October 26, 2020: member

    Concept ACK.

    I see this more as making the versioning scheme reflect reality than anything else. We already call our 0.X releases “major” and 0.X.Y releases “minor”, so the 0 doesn’t seem to convey any information whatsoever.

    I’m not opposed to a date-based YY.MM.minor scheme, though my personal preference is just dropping the zero.

  35. fanquake commented at 7:45 am on October 27, 2020: member

    Concept ACK

    I’m not opposed to a date-based YY.MM.minor scheme, though my personal preference is just dropping the zero.

    FWIW I am opposed to a date-based scheme. Let’s just drop the 0 and get this over with.

  36. ajtowns commented at 5:07 am on October 29, 2020: member
    Concept ACK. I’d also mildly prefer year based, but just dropping the zero is certainly simplest. Don’t see a practical benefit to putting consensus changes (particularly versus standardness changes) into the version.
  37. DrahtBot added the label Needs rebase on Nov 18, 2020
  38. Drop the leading 0 from the version number 
    Removes the leading 0 from the version number. The minor version, which
we had been using as the major version, is now the major version. The
revision, which we had been using as the minor version, is now the minor
version. The revision number is dropped. The build number is promoted to
being part of the version number. This also avoids issues where it was
accidentally not included in the version number.

The CLIENT_VERSION remains the same format as previous as previously,
the Major version was 0 so that was never a factor in CLIENT_VERSION.
    8f7b930475
  39. achow101 force-pushed on Nov 18, 2020
  40. DrahtBot removed the label Needs rebase on Nov 18, 2020
  41. jnewbery commented at 12:00 pm on November 20, 2020: member
    Code review ACK 8f7b930475
  42. MarcoFalke renamed this:
    Drop the leading 0 from the version number
    build: Drop the leading 0 from the version number
    on Nov 20, 2020
  43. MarcoFalke commented at 2:41 pm on November 20, 2020: member

    review ACK 8f7b93047581c67f2133cdb8c7845471de66c30f 🎻

    Signature:

     0-----BEGIN PGP SIGNED MESSAGE-----
 1Hash: SHA512
 2
 3review ACK 8f7b93047581c67f2133cdb8c7845471de66c30f 🎻
 4-----BEGIN PGP SIGNATURE-----
 5
 6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
 7pUhEvQv/XEWpw+MGd8t2Z0NBKwh4VaA481Jue+XJxqO3xrrcMdBiVAhMRhE5UFUR
 8GlkvkYOGhCUswat5u0aSOWNF9NxT8MygTeEnKYkeXw1lgXamStT27xqfawuJe3Lt
 9QI0+kp1EV2J7A3Owf+Q0QHFELIeNY6QhhrPID7EzUx2Y1NAZTiSsoWQIgatqqaaz
10/CqL2dRNQu170IR+z61spS21AyJ+GO/n4WpuNZPyqChuAKICmZcVQF+g0dIq5XU0
11DZoyoGeLzvlkSywGQuU8a5bEeU5tyY6Y6D6Q5YvfY45OYFy+IobQ3QBg090l9RzP
12i/mGR8SU27fOg1kwRjBeAEpaSE0lEaqp5vEJqgL71t/C+/dLhTucucE8rMk+zwEj
13zTZBPidZotEhXFRuU0x49QkFqSxCUNQKXcaidJ8qHCycfpZkeFC471ES5PEVSqgd
14cRUJ5+jgwqBdCHi0pfzEZ1GcndEPOC8Uyt1kzYSdelEojHem2Gj7UdXfD1Iq857c
15PVFYN2wb
16=TI+I
17-----END PGP SIGNATURE-----

    python: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory

  44. MarcoFalke merged this on Nov 20, 2020
  45. MarcoFalke closed this on Nov 20, 2020
  46. MarcoFalke commented at 2:45 pm on November 20, 2020: member
    (also tested that CLIENT_VERSION is unchanged)
  47. domob1812 referenced this in commit 793b8c2a83 on Nov 23, 2020
  48. laanwj referenced this in commit b0c9024a7c on Nov 23, 2020
  49. sidhujag referenced this in commit abdd7cf572 on Nov 23, 2020
  50. kallewoof commented at 4:44 am on November 27, 2020: member
    Fixes the closed-since-April #9653. Not sure what changed, but I’m happy about the decision obviously.
  51. MarcoFalke commented at 7:58 am on November 27, 2020: member
    I wouldn’t say anything changed. When it comes to user experience, p2p features, bugfixes, hardening, testing improvements, and literally everything else, the leading 0 in the version is an insignificant stylistic choice. We have enough “real” issues so that tracking issues for stylistic questions are probably eating away resources from more important topics ( #9653 (comment) )
  52. whitslack commented at 9:14 am on November 29, 2020: contributor
    I’m surprised nobody mentioned the obvious implication here: Bitcoin Core is now officially out of beta! 🚀
  53. sipa commented at 9:21 am on November 29, 2020: member
    It hasn’t had a “beta” label since 2014 (see #4221), and even then it was already hardly applicable.
  54. whitslack commented at 9:25 am on November 29, 2020: contributor

    From #4221:

    This is not to say that the system is mature now, suddenly.

    So are we now saying that the system is mature? 😄 Typically software projects use version numbers less than 1.0 to denote that their software is not yet production-ready. Advancing the version number to something greater than 1.0 sends the signal that the software is now ready for prime time.

  55. sipa commented at 9:31 am on November 29, 2020: member

    And that’s exactly what we wanted to avoid, by not going to 1.0, and instead just dropping the zero. We have for years been calling the X in 0.X.Y the major release number. I don’t know what mature means, but Bitcoin Core has had a release process with test procedures, multiple release candidates, goals of compatibility, … for a better part of a decade now.

    There is no dramatic change here, no big milestone, and no need for celebrations or whatever. It’s just dropping a zero that was redundant.

  56. mjdietzx referenced this in commit ae409294c1 on Dec 27, 2020
  57. mjdietzx referenced this in commit 8d1873b940 on Dec 27, 2020
  58. davidlj95 commented at 6:45 pm on November 15, 2021: none
    Guess we’ll need to update https://bitcoincore.org/en/lifecycle/ now that 22.0 is in place
  59. ghost commented at 7:15 pm on November 15, 2021: none
    @davidlj95 Yes I think it can be updated. Maybe try opening a issue/pull-request in https://github.com/bitcoin-core/bitcoincore.org/
  60. luke-jr referenced this in commit 6210399b47 on Dec 14, 2021
  61. UdjinM6 referenced this in commit 48bb3fd0c9 on Apr 28, 2022
  62. UdjinM6 referenced this in commit 37c6beb084 on Apr 28, 2022
  63. UdjinM6 referenced this in commit a3a7a22268 on Apr 28, 2022
  64. UdjinM6 referenced this in commit a064b4ca78 on Apr 28, 2022
  65. DrahtBot locked this on Nov 15, 2022


achow101 laanwj practicalswift hebasto Emzy michaelfolkson luke-jr fjahr DrahtBot JeremyRubin MarcoFalke jnewbery kristapsk promag theStack sipa fanquake ajtowns kallewoof whitslack davidlj95 ghost

Labels
Build system

Milestone
22.0

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 15:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me