Versioning convention for Bitcoin Core

kallewoof commented at 1:17 pm on January 30, 2017: member

In #8455 (comment) the versioning of Bitcoin Core was mentioned, but deemed off-topic, so I am creating this issue to address the fact that Bitcoin Core uses a non-traditional scheme for version releases.

To me, the first (traditionally “major”) version number is 0 for as long as a product is considered non-production-ready, and >0 for production-ready, and bears significant meaning in this sense.

Possible mind-sets:

It is agreed that Bitcoin Core is past beta stage, even if blockchains and crypto-currencies are new technologies. The initial 0. is dropped, meaning that the next version is 14.0 not 0.14.0.
A set of milestones leading up to a ‘production ready’ version of Bitcoin Core are established, and this is referred to as the 1.0 release.
This discussion is irrelevant.

laanwj added the label Brainstorming on Jan 30, 2017

laanwj commented at 1:37 pm on January 30, 2017: member

It is agreed that Bitcoin Core is past beta stage, even if blockchains and crypto-currencies are new technologies. The initial 0. is dropped, meaning that the next version is 14.0 not 0.14.0.

Feel free to discuss this. I’m mildly in favor of the idea of dropping the first number (I already do that in my head), but it’s certainly not going to change in the timespan until 0.14.

luke-jr commented at 5:18 pm on January 30, 2017: member

IMO the opposite of mindset 1 is true if anything: Bitcoin is in production use, even if implementations are still immature.

I think we have a long way to go before 1.0 would be a good idea… At the very least, I think we should have the code modular first so each component can get its own version at an appropriate time.

achow101 commented at 6:48 pm on January 30, 2017: member

This has been discussed many times before. I am in favor of simply dropping the 0. as that is essentially what the current versioning system is doing anyways. A lot of people already refer to the version numbers without the 0. anyways.

Leviathn commented at 4:53 am on January 31, 2017: none

I am of the opinion that moving from beta to ‘production’ - from 0.XX to X.XX - is inappropriate at this time. This transition can be used at a future point to indicate certain components are ‘finalized’ or the software has reached a certain, as-of-yet-unreached maturity state.

ghost commented at 9:50 am on January 31, 2017: none

I think this is not so important to bother with this

laanwj commented at 11:54 am on January 31, 2017: member

I am of the opinion that moving from beta to ‘production’ - from 0.XX to X.XX - is inappropriate at this time. This transition can be used at a future point to indicate certain components are ‘finalized’ or the software has reached a certain, as-of-yet-unreached maturity state.

Opinions differ greatly on this. Some people are of the opinion that bitcoin is pretty much finalized, and just polishing remains. It is used in production after all and is critical to quite a few people. Others think the largest changes are still ahead of us. There’s no point in having arguments about that because the future is, as always, unsure. This is a new field and no one is setting goalposts in cryptocurrency.

So no, it’s extremely unlikely that 0.x to 1.x will be used to signal anything. Just search the issues and mailing list a bit, this has come up many times before, with people asking as far back as in 2011 when the version will finally go to 1.x.

TheBlueMatt commented at 1:52 pm on January 31, 2017: member

Yea, let’s not make a big deal out of version numbers… They’re just numbers. Hell, if we don’t have anything else I’d recommend releases just take the number from the number of commits in them :p.

Indeed, I’ve been colloquially referring to versions without the “0.” for a while so have no problem making that change… Really my vote is @laanwj rolls a dice and picks something :).

On January 31, 2017 6:54:52 AM EST, “Wladimir J. van der Laan” notifications@github.com wrote:

I am of the opinion that moving from beta to ‘production’ - from 0.XX to X.XX - is inappropriate at this time. This transition can be used at a future point to indicate certain components are ‘finalized’ or the software has reached a certain, as-of-yet-unreached maturity state.

Opinions differ greatly on this. Some people are of the opinion that bitcoin is pretty much finalized, and just polishing remains. It is used in production after all and is critical to quite a few people. Others think the largest changes are still ahead of us. There’s no point in having arguments about that because the future is, as always, unsure. This is a new field and no one is setting goalposts in cryptocurrency.

So no, it’s extremely unlikely that 0.x to 1.x will be used to signal anything. Just search the issues and mailing list a bit, this has come up many times before, with people asking as far back as in 2011 when the version will finally go to 1.x.

– You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/9653#issuecomment-276344585

kallewoof commented at 2:06 pm on January 31, 2017: member

I apologize for dragging a dead horse out of its grave, so to say. I really should learn to search better, but the tools to do so aren’t super obvious to me.

My personal issue with this whole thing is that

We are calling “minor” versions “major” (at least if you look at e.g. semver [1])
We are clearly in production stages even if we may have unexpected beta-like events in the future due to the experimental nature, but are still claiming to be pre-production (saying bitcoin is beta and not used in real life is obviously incorrect).
Anyone who, like me, interprets <1.0 as “don’t use for serious stuff” will be mislead into avoiding the software. Then again, a healthy dose of lack of trust may be the healthiest thing to have in this situation.

[1] http://semver.org

Leviathn commented at 4:51 pm on January 31, 2017: none

@laanwj I think approaching this so casually misses my point : there’s an opportunity to utilize the transition from o.XX to X.XX as a branding/external command event. Having a natural transitive stage as this is a nice-to-have, and should not be discarded lightly.

Leviathn commented at 4:52 pm on January 31, 2017: none

**external comment event

MarcoFalke commented at 1:19 am on February 1, 2017: member

@Leviathn, I doubt we can ever agree on when to name the version 1.0.0 instead of 0.XX.XX. Right now Bitcoin Core is doing a rolling release about every 6 months (and minor releases whenever applicable). The version number pretty much only tells in what order the releases were made.

The difficulty to decide when to tag it version 1.0.0 arises when you realize that Bitcoin Core is pretty much a massive bundle of different modules (c.f. the folders in /src or the slide at https://youtu.be/8BLWUUPfh2Q?t=2h46m19s). And even if you could decide for a single of those modules that it reached version 1.0.0, we can just put “Bitcoin Core 21.0.0 comes bundled with a stable release of Core Wallet 1.0.0” in the release notes, even though other parts of the software may be less mature than most stable part at that time.

Lets jut get rid of the idea that a semi-arbitrary number that happens to denote the version of a Bitcoin Core release implies that the maturity of the software or even of the whole Bitcoin network is reached. Otherwise, when version 1.0.0 means “stable”, does 2.0.0 mean “more stable”? If so, we can just use 15.0 and 16.0 and say “a larger number implies that the sofware is (slightly) more stable”. In this context, Matts proposal to use the number of commits makes most sense, but I think sticking with the existing process and just increment the number every release is easier to handle.

I think dropping the 0 prefix is the easiest way to get rid of the regular discussion to bump to 1.0.0.

JeremyRubin commented at 3:05 am on February 1, 2017: contributor

NACK on using number of commits.

For instance, “Bitcoin v12821” (commits at time of writing) should not be used because it isn’t a tagged release and numbering by commits implies that it is.

TheBlueMatt commented at 3:07 am on February 1, 2017: member

Sorry, that wasn’t a serious proposal, indeed the usability issues of that are too high. It was only a demonstration of how little effort I think we should put into this issue.

On January 31, 2017 10:05:50 PM EST, Jeremy Rubin notifications@github.com wrote:

NACK on using number of commits.

For instance, “Bitcoin v12821” (commits at time of writing) should not be used because it isn’t a tagged release and numbering by commits implies that it is.

– You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/9653#issuecomment-276561018

JeremyRubin commented at 4:19 am on February 1, 2017: contributor

I disagree. Version numbers are pretty important for users!

I think that overall an acceptable “compromise” would be to jump versions by a few and release 0.14 as Bitcoin 17 to mean Bitcoin 2017. If there are multiple releases intended in a given year, then it should be marked as YY.MM, eg 17.02 for a release in February 2017. This is how Ubuntu does it IIRC, and it works pretty well I think (we’d never really do 2 versions in a month…). A downside is that if, for some reason, there is no release for a year you skip a version number! Any releases can be handled as a counter at the end, e.g., 17.02.011, 17.02.012.

unsystemizer commented at 8:30 am on February 1, 2017: contributor

I don’t like the idea of commits (they don’t mean anything) nor the idea of jumping from v0.1x to v1(x+1) for the sake of marketing or image.

I am in favor of option 2) (agree on a set of milestones leading to v1.0.0) but if only if SemVer is adopted at the same time (otherwise there’s no point in trying to attach meaning to any version string, now or in the future).

v1.0.0 could be introduced instead of v0.2.0 (or any other soon-ish release) as part of official transition to SemVer versioning, for example.

To me, the first (traditionally “major”) version number is 0 for as long as a product is considered non-production-ready, and >0 for production-ready, and bears significant meaning in this sense.

I agree, but let’s also consider the meaning of the rest (minor.patch). IMHO SemVer is the main reason why this should be done and it addresses all three (major, minor, patch).

laanwj commented at 8:32 am on February 2, 2017: member

I think sticking with the existing process and just increment the number every release is easier to handle.

Yes, indeed. We have a strictly time-based release process: a major release every 6 months, minor releases as necessary. Every major release, the second number is increased. This is completely predictable and requires zero discussion, which makes it very efficient.

As there are always two major releases per year, this also means that @JeremyRubin’s idea to go to purely year-month based version numbers isn’t that crazy. For major releases, minor releases would still get a .x as they are fixups to older releases. This is the same for Ubuntu: Ubuntu 14.04.5 LTS (Trusty Tahr). First number is the year, second the month of that (major) release, third number is the update (“point-release”).

Victorsueca commented at 10:47 am on February 17, 2017: none

I agree with number 2

About what @MarcoFalke said…

Otherwise, when version 1.0.0 means “stable”, does 2.0.0 mean “more stable”? If so, we can just use 15.0 and 16.0 and say “a larger number implies that the sofware is (slightly) more stable

I don’t know how does other people feel about that, but for me 2.x.x always implied that it has been overhauled and/or most, or the most important parts, of the code have been rebased.

MarcoFalke commented at 11:02 am on February 17, 2017: member

As I understand semver does not care about the quality of the code base or the maturity of the software at all. If we decide to adopt semver, our version number pretty much only indicates what happens with the public api.

http://semver.org/#spec-item-5

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

kallewoof commented at 6:54 pm on February 17, 2017: member

Ideal is that patch bump (z in x.y.z) = “we broke something, we fixed it, oops”; minor bump (y) = “we fixed minor stuff and/or streamlined/polished”; major bump (x) = “we are releasing new stuff”.

In that context, maturity and quality increase at y and z bumps and maturity resets at x bumps. (I think it’s tailored truth to say that quality of code increases at x bumps, even if that is of course ideal.)

Leviathn commented at 8:54 pm on May 14, 2017: none

Did we come to conclusion here? Or are we punting?

kallewoof commented at 7:38 am on October 4, 2017: member

Now that btc1 have hijacked the version of Bitcoin, I think the best way forward is to adopt the versioning system proposed by Jeremy Rubin using year and month (Ubuntu style), as we now run a big risk of new users seeing “1.14 and 0.15” and thinking the former is newer.

JeremyRubin commented at 4:59 pm on October 4, 2017: contributor

@kallewoof I agree this is good to do. I don’t think it will be super-effective against btc1 confusion, because they may also elect to use this release system (although perhaps not).

If there is no strong opposition, perhaps you/we should draft a more formal documentation change to make this clear.

I would propose that to do this we do an immediate release which reversions the latest release (0.15.0.1) as 17.10.x. This would change the Schedule for 0.16 #11449 to be releasing version 18.5.1.

If we also want to do something like Ubuntu with having adj+animal releases, maybe something like ‘Bumpy Barnacle’ or ‘Boisterous Beagle’.

TomasJuocepis commented at 5:43 am on October 16, 2017: none

If we also want to do something like Ubuntu with having adj+animal releases

If/when releases start getting nicknames, I’d really prefer iterating over a different subject - not animal names - and big bonus if that subject has meaning to crypto. I suggest adj+math/cs/crypto term. Adjective also being a math/cs/crypto term is a bonus. Some examples:

A: asymmetric alice (homage to private/public cornerstone of crypto and the beloved Alice)
B: brazen bit(coin)
C: crypto cipher
D: distributed decryption
E: encrypted entropy
F: …drawing a blank…
G: geometric gold
H: homomorphic hash
I: immutable information … etc, you get the point.

meshcollider commented at 5:47 am on October 16, 2017: contributor

FWIW I don’t like the idea of a name at all, version numbers are clean, simple and easy to come up with ;)

JeremyRubin commented at 5:45 pm on October 16, 2017: contributor

@TomasJuocepis disagree. This will be confusing for users expecting there to be a feature relating to that. names should be somewhat irrelevant. @MeshCollider There is a simple reason for it, you need a stable name for the version pre-release.

jnewbery commented at 8:24 pm on October 16, 2017: member

I also prefer to not use names. We’re generally only working on one release at a time. The stable name for the version pre-release is ’the next version'.

JeremyRubin commented at 0:26 am on October 17, 2017: contributor

‘The next version’ doesn’t help for searching through email archives

TomasJuocepis commented at 5:19 am on October 17, 2017: none

@JeremyRubin, it’d be a stretch to interpret most of the listed names as actual features. I think you’re not giving enough credit to the users’ competence. Having said that, I see your point and mostly agree. After thinking more about it, I think the bigger issue would be not the user confusion, but occasional accidental confusion during discussions when mentioning the version names in the context of similar concepts and terminology being discussed. I guess I’d be happy with Alice Core, Bob Core, Carol Core, … the Core family.

vinniefalco commented at 2:54 am on December 23, 2017: contributor

Projects which drag on for years with versions below 1 look unprofessional, as if they are either unfinished or as if the people running the project are stereotypical programmers who can’t be bothered with hygiene or their personal appearance. The next version should be labeled 1.0 and it should be planned with maximum fanfare and social media coordination.

vinniefalco commented at 2:58 am on December 23, 2017: contributor

Yes, indeed. We have a strictly time-based release process: a major release every 6 months, minor releases as necessary. Every major release, the second number is increased. This is completely predictable and requires zero discussion, which makes it very efficient.

If this is the case then the year followed by the minor version is sensible, e.g. 18.0, 18.1, 19.0, 19.1, and so forth.

luke-jr commented at 3:25 am on December 23, 2017: member

@vinniefalco Bitcoin and Bitcoin Core aren’t finished or ready for mainstream use. 0.x fits perfectly to convey a correct understanding on this.

vinniefalco commented at 3:46 am on December 23, 2017: contributor

0.x fits perfectly to convey a correct understanding on this.

I agree that 0.x implies “not finished or ready for mainstream use.”

Bitcoin and Bitcoin Core aren’t finished or ready for mainstream use

The optics on this are even worse than using a beta version number to label a finished product. Is it possible that perhaps the criteria for “finished” are either impossible to achieve or poorly defined?

luke-jr commented at 5:37 am on December 29, 2017: member

@vinniefalco No, the criteria are not impossible nor poorly defined.

sipa commented at 5:46 am on December 29, 2017: member

I’m in favor of dropping the zero.

I disagree that there will be a point where a discrete transition from “immature” to “mature” will happen. No software is ever finished, but the procedures this project is following (testing, compatibility across versions, release schedule, …) certainly already follow an expectation of stable interfaces and operation. I believe that is a better criterion anyway than a vague “ready for mainstream use” (certainly our software’s versioning shouldn’t depend on its audience or on the currency’s adoption).

As a result, I think the 0 is just redundant. Of the various ways to proceed I think shifting up the digits has the least risk of incorrectly being interpreted as a major event instead of just recognizing that the zero serves no purpose.

intelliot commented at 6:02 am on December 29, 2017: none

@luke-jr Honest question - what are the criteria?

luke-jr commented at 6:24 am on December 29, 2017: member

@sipa No software is ever finished, but being reasonably ready for mainstream use before leaving 0.x seems like an obvious criteria to wait for. I’m sure we could come up with a more specific definition if that’s important to some people, but it’s pretty obvious we’re not there yet either way.

chriswheeler commented at 11:18 am on December 29, 2017: contributor

@luke-jr You say that “the criteria are not impossible nor poorly defined” - where are they defined at all?

My vote would be for using SemVer 2.0.0 - and move to that by dropping the current “0.” prefix.

Could we then increment the MAJOR version for API breaking changes, (or even, a hypothetical future hard fork version) the MINOR version for a version which contains a soft fork or backwards compatible API change and the PATCH for bug fixes?

promag commented at 11:56 am on December 29, 2017: member

We had 0.15.0.1 for instance and IMO that sounds confusing to users.

but it’s pretty obvious we’re not there yet either way. @luke-jr what would be considered ready for mainstream?

Anyway, I like this policy https://www.postgresql.org/support/versioning/.

luke-jr commented at 12:01 pm on December 29, 2017: member

@promag A few obvious things that come to mind (not intended to be a comprehensive list):

“Just works” fee handling. It’s too easy to get stuck transactions, even today.
Some simple way to setup automatic encrypted remote backups.
Some simple way to actually restore backups.

Part of the problem here is that Core includes so many different things at different stages of development. The consensus code should probably be something like version 2.4.1, but the wallet stuff is far from ready for a 1.0.

h0jeZvgoxFepBQ2C commented at 1:54 pm on December 29, 2017: none

I’m in favour of dropping the 0 and using a semver 2.0 style.

I dislike the Debian style with naming each release (i have to look up each time someone references a release name), and I also dislike timeframe specific versions like Ubuntu, because it doesn’t include any information how much has changed and if there are any breaking changes.

vinniefalco commented at 2:39 pm on December 29, 2017: contributor

@luke-jr I cloned the repo and tried to build it on Windows. I also ran the installer version and synced. I agree with you somewhat now, it isn’t in the best shape.

morcos commented at 4:08 pm on December 29, 2017: member

I’m pretty strongly in favor of the HARDFORK.MAJOR.MINOR versioning scheme mentioned here: #12026 (comment)

Did I miss some discussion as to why people are opposed to this? This would put the versioning scheme to very good use in conveying important information. If we ever have a hard fork, it’ll be important that everyone is running a compatible client. To some extent it doesn’t matter now whether you are running 0.11 or 0.16. But after a hard fork, it’ll matter that everyone is running 1.something.

promag commented at 4:55 pm on December 29, 2017: member

I don’t understand why we should tie hardfork number and bitcoin core version.

pauldemarco commented at 5:28 pm on December 29, 2017: none

I think the solution would require a couple things:

A way to indicate major changes to the consensus rules, requiring a hard fork.
A way to indicate significant software inprovements/features.
A way to indicate minor patches to aforementioned features.
Seamless transition from the current state so it doesn’t seem a major event took place, and cause a stir.

With all the above, I think the best solution would be: <HARD_FORK>.<MAJOR_VERSION>.<MINOR_VERSION>

This would both satisfy the above requirements, and not require a change to the current state until the next hard fork is needed.

On Dec 29, 2017 11:56 AM, “João Barbosa” notifications@github.com wrote:

I don’t understand why we should tie hardfork number and bitcoin core version.

— 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/issues/9653#issuecomment-354471093, or mute the thread https://github.com/notifications/unsubscribe-auth/AP829lyP11y1klaustC9LQDjIM-Gwiayks5tFRmmgaJpZM4LxY7j .

morcos commented at 6:20 pm on December 29, 2017: member

@promag How do you expect people to easily know whether they are running compatible software after the hard fork other than by the version number?

promag commented at 6:34 pm on December 29, 2017: member

What I mean is that the first component could be increased not only because of a hard fork.

As others suggested, I like semver2 major.minor.patch where a major change could mean hard fork or something else (for instance changing wallets to leveldb or new rpc api). This gives the patch component, useful when there are backports.

coyotte508 commented at 11:08 pm on December 29, 2017: none

@promag From 2014 to now the highest a minor version number has been was 4 (0.10.4) or 3 otherwise. In 2013 there was 0.8.6.

The minor version number is already used underwhelmingly, adding a patch component seems like a waste.

jtimon commented at 11:11 pm on December 29, 2017: contributor

To reiterate from the other thread, we’re currently doing softforks as minor versions and I think we should do the same for hardforks. Alternatively, we could increment the first number with either hardforks or softforks. Both are consensus changes and I don’t see why hardforks should have special treatment in the versioning. So, either way, nack on the <HARD_FORK>. part.

promag commented at 0:38 am on December 30, 2017: member

@coyotte508 the <HARD_FORK>. part would be used even more underwhelmingly. Don’t forget there is 0.15.0.1 which with semver2 wouldn’t exist.

meshcollider commented at 3:12 am on December 30, 2017: contributor

To me it seems tangent to be discussing hardforks, this is just the version number for Bitcoin Core not the Bitcoin protocol

laanwj referenced this in commit db7eba6169 on Dec 30, 2017

ajtowns commented at 11:16 am on December 30, 2017: member

If a hardfork was deployed in a planned manner with a year or more activation delay, I don’t think encoding it in a version scheme would make much sense: there’d be multiple releases with hardfork support before the pre-hardfork software is unable to follow the chain.

I don’t think there’s much value to adding a hard fork counter: at the time the hard fork’s about to activate, you just have to say “the current version is 25.2.3, make sure you’re upgraded to at least version 19.0.0 to cope with the hard fork coming next week”. In that scenario, using hardfork-major versioning seems mislading: 0.18 and 1.19 aren’t incompatible and won’t be for a few years.

MarcoFalke commented at 2:45 pm on January 11, 2018: member

I’m pretty strongly in favor of the HARDFORK.MAJOR.MINOR versioning scheme mentioned here: #12026 (comment)

Did I miss some discussion as to why people are opposed to this? This would put the versioning scheme to very good use in conveying important information. If we ever have a hard fork, it’ll be important that everyone is running a compatible client. To some extent it doesn’t matter now whether you are running 0.11 or 0.16. But after a hard fork, it’ll matter that everyone is running 1.something.

I agree that a version that implements a hard forking change should prominently convey this information. However, I highly disagree that a hard fork should be accompanied by a version bump. That falsely also conveys (to some) that a hard fork is always better that a previous version that does not implement the hard fork. (The version number is larger, so it must be better, …)

Also, bumping the version number in case of a hard fork implementation does not work very well with backports. Assume a hard fork in version 0.x is backported to version 0.(x-1), you can’t really bump both to the same 1.0.0 version…

I see two ways to convey that a software version implements a hard fork:

Mention it in the software name or other prominent place. E.g. instead of “Bitcoin Core” it is “Bitcoin Core ${FEATURE}”
Use a field in the version number to indicate that a hard fork was implemented. So the first hard fork gets the number “1”, which is also backported along with the hard fork code changes to previous versions. E.g. a hard fork can be backported to version x and x-1, becoming 1.x and 1.(x-1), respectively. Though, that again comes with the downside of assigning numbers to hard forks, where a higher number is often interpreted as “better”.

MarcoFalke commented at 0:18 am on April 27, 2020: member

The feature request didn’t seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.

MarcoFalke closed this on Apr 27, 2020

intelliot commented at 1:47 am on April 27, 2020: none

However, I highly disagree that a hard fork should be accompanied by a version bump. That falsely also conveys (to some) that a hard fork is always better that a previous version that does not implement the hard fork. (The version number is larger, so it must be better, …)

A hard fork should be better than a previous version that does not implement the hard fork. Otherwise, why bother to do the release at all? Also, there are plenty of examples of software where larger version numbers are not better than older versions (at least in the opinion of some users). It’s why sites like Old Version exist. So I don’t think this particular aspect is a downside.

MarcoFalke locked this on Feb 15, 2022

Versioning convention for Bitcoin Core #9653