Prepare version scheme for upcoming release [take 2] #12055

Preface: Obviously, this does not mean Bitcoin Core is all of a sudden less experimental than before. This changes only the version string.

This prepares the version scheme for the upcoming release. Instead of referring to master as 0.15.99, we can refer to it as 15.99. Or 0.17.0 will become 17.0.0.

The current version scheme is 0.MAJOR.MINOR, c.f. https://bitcoincore.org/en/lifecycle/#versioning. The proposed version scheme is MAJOR.MINOR.0, i.e. dropping the constant prefix 0..

Participants of #9653 also proposed other versioning schemes, which come with downsides:

• The version scheme MAJOR_YEAR.MAJOR_MONTH.MINOR, where MAJOR_YEAR and MAJOR_MONTH refer to when the release cycle started. For version numbers to be predictable (like they are for ubuntu), we'd had to either prepare a release every 6 months or come up with a name for "the next version". Neither solution is feasible for this project.
• The 1.0.0 version scheme. This is also infeasible as outlined in #9653 (comment) and subsequent comments.

So I'd propose to stick with the existing version scheme or drop the leading zero.

C.f. #12026

1.0.0 isn't infeasible at all. We're just not there yet.

This ignores the purpose of the current 0., and tries to "fix" what isn't broken. As such, it remains a bad idea. NACK

utACK https://github.com/bitcoin/bitcoin/pull/12055/commits/faae28233446df1dcd29fc8f456db923d1a44f0c

@MarcoFalke what is the purpose of the 3rd part if it's always 0?

Should be used for fixes such as the one in 0.15.0.1, imo.

Concept ACK.

I tend to agree with @luke-jr and put my NACK here. Also, this seems in general be controversial (see #9653).

From the "inner" perspective, it's just a version number. But from the "outer" angle, it may have more consequences then we would expect.

Since everything still runs in a single process, may be partial unresponsive (GUI) without any notice during heavy verification load, GUI is still immature for an "electronic peer to peer cash system" (sorry to mention that here), I think version 0.MAJOR.MINOR is still adequate.

ACK.

Not because I believe we have passed some major milestone, but because I don't believe such a milestone will happen anymore. As a result, I think the 0 is an artifact that we'll either be stuck with forever, or at some point (now or later) arbitrarily remove.

While I agree that lots of work remains, and more in some parts of the software than others, this does not imply immaturity. No software is ever finished. We're treating the X in 0.X.Y as the major version number already (and have been calling it that way as long as I remember), with a long well-established release process along it. It is used by many in production environments, and we strongly care about compatibility across versions to enable that.

I certainly don't think Bitcoin is "done", but Bitcoin Core is a mature client for the protocol as it exists today.

FWIW I think by far this is the most sensible answer: HARDFORK.MAJOR.MINOR.[REVISION] much as was suggested in this comment.

If there is a hard fork tomorrow you can go from v0.15.0.1 to v1.15.1 or similar.

@Willtech I've pointed out before, that this is simply a version number for bitcoin core software, not for the bitcoin protocol/consensus rules. A hardfork is related to the latter, while it should not be the deciding factor for the former's version number.

Bitcoin is already widely used in production. Your 0. warning has been falling on deaf ears for years now, which is mostly your own fault for writing such high quality code. @jonasschnelli:

But from the "outer" angle, it may have more consequences then we would expect.

I think if this project goes directly from 0.16.x to 17.0.0 no one will make any blind assumptions about what that means. Include in the changelog that you're just changing the versioning scheme.

Rebased