<p>Usually the code is written, tested, and merged into the release, and then deployed <em>switched off</em>.  Depending on the change, it can then be activated on a particular date, block, when the network has a consensus (certain %age of people agree to implement it), or when <em>x</em> number of blocks mined support the new change.</p>

<p>Code can be hard, or soft forked, and the developers attempt to make changes backwards compatible as much as possible to avoid client issues.</p>

<p>Occasionally incompatible clients can generate odd blocks (like for example a recent 1.01MB block) that get orphaned, or discarded by the rest of the network. Or even a chain of several blocks that get orphaned, this is one of the reasons you should wait for more than one successful confirmation after transferring money.</p>

CC BY-SA 3.0
2017-06-09T12:34:21.750Z
2017-06-09T12:34:21.750Z
Daniel Morritt
<p>Almost all changes made to the Bitcoin protocol so far where backwards compatible in that they only restricted the ruleset of acceptable behavior on the network. Therefore, if the new rules where enforced by a majority of the current hashrate, any older software would follow along on the same blockchain as the rules they expected to be followed allowed a superset of the currently enforced behavior.</p>

<p>So, the main idea is that there is only one version of the protocol enforced at the same time.</p>

CC BY-SA 3.0
2017-06-09T15:23:23.867Z
2017-06-09T15:23:23.867Z
Murch
<p>How does Bitcoin deploy new features and manage different versions compatibility?</p>

<p>For example if a new feature is added to Bitcoin, how is that then deployed and managed? That is, how is everyone on the network not forced to upgrade when a new version is available?</p>

<p>If an upgrade/update is not forced, how does Bitcoin manage different versions of Bitcoin on the network? Is there a minimum required version somehow distributed amongst the network?</p>

<protocol><bitcoin-core-development><consensus><bip>
How are code changes (e.g. new features) to applications such as Bitcoin deployed and how is compatibility mainted?
Greg
# How are code changes (e.g. new features) to applications such as Bitcoin deployed and how is compatibility mainted?

(Asked by: username_0 on 2017-06-09)

How does Bitcoin deploy new features and manage different versions compatibility?

For example if a new feature is added to Bitcoin, how is that then deployed and managed? That is, how is everyone on the network not forced to upgrade when a new version is available?

If an upgrade/update is not forced, how does Bitcoin manage different versions of Bitcoin on the network? Is there a minimum required version somehow distributed amongst the network?

**Tags:** protocol, bitcoin-core-development, consensus, bip


---

## 2 answers

### Answer by username_1 on 2017-06-09. Score: 3 | Accepted answer

Usually the code is written, tested, and merged into the release, and then deployed *switched off*. Depending on the change, it can then be activated on a particular date, block, when the network has a consensus (certain %age of people agree to implement it), or when *x* number of blocks mined support the new change.

Code can be hard, or soft forked, and the developers attempt to make changes backwards compatible as much as possible to avoid client issues.

Occasionally incompatible clients can generate odd blocks (like for example a recent 1.01MB block) that get orphaned, or discarded by the rest of the network. Or even a chain of several blocks that get orphaned, this is one of the reasons you should wait for more than one successful confirmation after transferring money.


---

### Answer by username_2 on 2017-06-09. Score: 2

Almost all changes made to the Bitcoin protocol so far where backwards compatible in that they only restricted the ruleset of acceptable behavior on the network. Therefore, if the new rules where enforced by a majority of the current hashrate, any older software would follow along on the same blockchain as the rules they expected to be followed allowed a superset of the currently enforced behavior.

So, the main idea is that there is only one version of the protocol enforced at the same time.


---

