build: Drop the leading 0 from the version number

[achow101]

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.

[laanwj]

Concept ACK

[practicalswift]

Concept ACK: a.) number go up is good, and b.) big number going up is obviously better than small number going up! :)

[hebasto]

Concept ACK for 0.22.0 -> 22.0

[Emzy]

Concept ACK for 0.22.0 -> 22.0

[michaelfolkson]

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... :)

[luke-jr]

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.

[fjahr]

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.

[DrahtBot]

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• build: Decouple clientversion.cpp from the git repo #18980 (build: Decouple clientversion.cpp from the git repo by hebasto)
• Erlay: bandwidth-efficient transaction relay protocol #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.

[JeremyRubin]

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.

[maflcko]

Concept ACK

Assigned 22.0 milestone

[jnewbery]

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

[kristapsk]

I tend to agree with @luke-jr here.

[promag]

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.

[practicalswift]

@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)? :)

[luke-jr]

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.

[promag]

@luke-jr fundamentally different? At the time, if it was 19.0.0, we would just tag 19.0.1, or am I wrong?

[luke-jr]

@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...

[luke-jr]

(Hmm, unless we decide softforks count as minor features?)

[theStack]

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.

[luke-jr]

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

[maflcko]

review ACK 8f7b930 🎻

Show signature and timestamp

Signature:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

review ACK 8f7b93047581c67f2133cdb8c7845471de66c30f 🎻
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUhEvQv/XEWpw+MGd8t2Z0NBKwh4VaA481Jue+XJxqO3xrrcMdBiVAhMRhE5UFUR
GlkvkYOGhCUswat5u0aSOWNF9NxT8MygTeEnKYkeXw1lgXamStT27xqfawuJe3Lt
QI0+kp1EV2J7A3Owf+Q0QHFELIeNY6QhhrPID7EzUx2Y1NAZTiSsoWQIgatqqaaz
/CqL2dRNQu170IR+z61spS21AyJ+GO/n4WpuNZPyqChuAKICmZcVQF+g0dIq5XU0
DZoyoGeLzvlkSywGQuU8a5bEeU5tyY6Y6D6Q5YvfY45OYFy+IobQ3QBg090l9RzP
i/mGR8SU27fOg1kwRjBeAEpaSE0lEaqp5vEJqgL71t/C+/dLhTucucE8rMk+zwEj
zTZBPidZotEhXFRuU0x49QkFqSxCUNQKXcaidJ8qHCycfpZkeFC471ES5PEVSqgd
cRUJ5+jgwqBdCHi0pfzEZ1GcndEPOC8Uyt1kzYSdelEojHem2Gj7UdXfD1Iq857c
PVFYN2wb
=TI+I
-----END PGP SIGNATURE-----

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

[maflcko]

(also tested that CLIENT_VERSION is unchanged)

[kallewoof]

Fixes the closed-since-April #9653. Not sure what changed, but I'm happy about the decision obviously.

[maflcko]

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) )

[whitslack]

I'm surprised nobody mentioned the obvious implication here: Bitcoin Core is now officially out of beta! 🚀

[sipa]

It hasn't had a "beta" label since 2014 (see #4221), and even then it was already hardly applicable.

[whitslack]

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.

[sipa]

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.

[davidlj95]

Guess we'll need to update https://bitcoincore.org/en/lifecycle/ now that 22.0 is in place

[ghost]

@davidlj95 Yes I think it can be updated. Maybe try opening a issue/pull-request in https://github.com/bitcoin-core/bitcoincore.org/