Prepare version scheme for 17.0 release #12026

1. 
   MarcoFalke commented at 1:25 pm on December 26, 2017: member

   This prepares the version scheme for the upcoming 17.0.0 release (formerly known as 0.17.0). After branching off 0.16.0, we could start referring to master as 16.99.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.

   EDIT: Obviously, this does not mean Bitcoin Core is all of a sudden less experimental than before.

2. Prepare version scheme for 17.0 release faa7ecf8ba
3. MarcoFalke force-pushed on Dec 26, 2017
4. 
   meshcollider commented at 9:59 pm on December 26, 2017: contributor

   Concept ACK.

   I believe we’ve only ever used the ‘patch’ number for 0.9.2.1 and 0.15.0.1, it’s usually unused so it’d be clearer in most cases to leave it off in the new version scheme too, and make it the standard to just use 17.0, etc.

5. 
   ChainQuery commented at 10:28 pm on December 28, 2017: none

   ACK - This would seem to indicate that the days of being considered in beta are over?
6. 
   DavidVorick commented at 1:00 am on December 29, 2017: none

   People read into version numbers a lot. They are important because it tells people at a very quick glance about the maturity and stability of a project.

   Despite protests from some developers, I think Bitcoin at this point can be considered both mature and stable, especially from a software-compatibility perspective. So I am in favor of upgrading to v17.0.0 as the new naming scheme. Other than dropping the leading zero, I don’t think anything else needs to be changed - the Bitcoin core naming scheme is already pretty reasonable.

7. 
   botolo commented at 2:50 am on December 29, 2017: none

   I am just a user, so please forgive me if my comment does not make sense in developers’ language. As I user, I would expect to see Bitcoin Core go from 0.XX to 1.0 once the software is considered sufficiently mature to leave beta.
8. 
   whitslack commented at 3:56 am on December 29, 2017: contributor

   Bitcoin is not ready to exit beta status, as a break from 0.x would imply. There is a long way to go before Bitcoin is “production-ready.” When Bitcoin can be used smoothly as a currency (fast commit, negligible per-transaction fees, and buttery smooth user experience with all the bells and whistles), then and only then should Bitcoin advance from 0.x.

   Please, let’s not go down the path of Chromium. “Version 63.0” of any software is just stupid. The first version component should only be incremented upon the introduction of major breaking changes. With strong development practices and a lot of foresight and planning, a “2.0” should never be necessary, let alone a “17.0”.

9. 
   pauldemarco commented at 4:00 am on December 29, 2017: none

   That would imply that there has been 17 major versions, is this true?

   On Dec 28, 2017 9:51 PM, “botolo” notifications@github.com wrote:

   I am just a user, so please forgive me if my comment does not make sense in developers’ language. As I user, I would expect to see Bitcoin Core go from 0.XX to 1.0 once the software is considered sufficiently mature to leave beta.

   — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/12026#issuecomment-354390447, or mute the thread https://github.com/notifications/unsubscribe-auth/AP829uAWz6UesD6WemvlLDn6EL_g2j0vks5tFFO2gaJpZM4RMxHu .

10. 
    fanquake commented at 4:01 am on December 29, 2017: member

    Please take any general versioning comments/discussion to #9653, otherwise this PR is just going to rehash a lot of what has already been discussed in that issue for the past year.
11. 
    achow101 commented at 4:02 am on December 29, 2017: member

    Concept ACK @botolo @whitslack, please see #9653 for the discussion about this. @pauldemarco yes. Each 0.X release has basically been a major release and referred to as such.
12. 
    jaggli commented at 4:40 am on December 29, 2017: none

    Is there a reason, for not using semver https://semver.org ? MAJOR.MINOR.PATCH
13. 
    mattbailey commented at 4:40 am on December 29, 2017: none

    As just a user (but also a dev) I support going to v17.0.0. facebook/react did something similar with v0.14.x to v15.x.x, so it’s not without president. Then just semver from there.
14. 
    fanquake commented at 4:41 am on December 29, 2017: member

    @jaggli That has been discussed extensively in #9653.
15. 
    luke-jr commented at 5:37 am on December 29, 2017: member

    Concept NACK, for all the same reasons already discussed in #9653
16. 
    zaowens commented at 6:22 am on December 29, 2017: none

    “Please, let’s not go down the path of Chromium. “Version 63.0” of any software is just stupid. "

    I would like to point out the fact that assuming bitcoin is regularly updated until and after the year 2140 when all 21,000,000 coins are in circulation, regardless of the version scheme it will likely be a “stupid” software version >63.0

17. 
    KittiesInLove commented at 8:23 am on December 29, 2017: none

    I propose X.MAJOR.MINOR where MAJOR = 1 digit and MINOR <= 2 digits 0.16.0 -> 0.2.0 0.2.11 0.3.0 0.9.0 -> … 1.2.21

    This solution avoids the „Chromium way“, comes over the leading 0 soon, deals with the beta argument and is easy to get for everyone.

18. 
    blumenkraft commented at 8:50 am on December 29, 2017: none

    Why not just make the constant prefix zero a non-constant? Make this thing a 1.0, it deserves it.
19. 
    kallewoof commented at 9:05 am on December 29, 2017: member

    Strong ACK
20. 
    coyotte508 commented at 10:19 am on December 29, 2017: none

    Why not make it HARDFORK.MAJOR.MINOR?

    1.0.0 will be the first hardfork, 2.0.0 the second hardfork and so on.

21. 
    whitslack commented at 2:53 pm on December 29, 2017: contributor

    HARDFORK.MAJOR.MINOR is a lot closer to SemVer, as it preserves the notion of incompatible changes for the first version component. A hard fork is certainly an incompatible change.

    But as has been mentioned, this is already pretty much decided, and this is not the thread to discuss it.

22. 
    jtimon commented at 3:49 pm on December 29, 2017: contributor

    utACK. Perhaps 16.99.99 instead of 16.99.0? @coyotte508 @whitslack I disagree, I think we should make hfs in minor versions just like we do sfs. But we should probably take that discussion to #9653
23. 
    laanwj commented at 10:51 am on December 30, 2017: member

    utACK faa7ecf
24. laanwj merged this on Dec 30, 2017
25. laanwj closed this on Dec 30, 2017

    ---

26. laanwj referenced this in commit db7eba6169 on Dec 30, 2017
27. MarcoFalke deleted the branch on Dec 30, 2017
28. 
    laanwj commented at 11:19 am on December 30, 2017: member

    This was accidentally merged, and reverted db7eba6 → efae366.
29. fanquake deleted a comment on Jan 2, 2018
30. fanquake locked this on Jan 2, 2018

Contributors
MarcoFalke meshcollider ChainQuery DavidVorick botolo whitslack pauldemarco fanquake achow101 jaggli mattbailey luke-jr zaowens KittiesInLove blumenkraft kallewoof coyotte508 jtimon laanwj