<blockquote>
<p>What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the functional tests?</p>
</blockquote>
<p>There is a <a href="https://github.com/bitcoin/bitcoin/blob/master/test/functional/feature_backwards_compatibility.py" rel="nofollow noreferrer">feature_backwards_compatibility.py</a> functional test which spins up functional test nodes from each of the previous releases to do testing between them at the same time.</p>
<p>Once you have built the latest version of Bitcoin Core you can download the previous release binaries using:</p>
<p><code>test/get_previous_releases.py -b v0.19.1 v0.18.1 v0.17.2 v0.16.3 v0.15.2</code></p>
<p>You can then run the <code>feature_backwards_compatibility.py</code> test individually or through the test runner.</p>
<p>e.g. <code>test/functional/test_runner.py feature_backwards_compatibility.py</code></p>
<p>This test is updated with each new release to add a functional test node from the latest release to functional test nodes from previous releases.</p>
<p>At the time of writing (December 2020) there is an open <a href="https://github.com/bitcoin/bitcoin/pull/19013" rel="nofollow noreferrer">pull request</a> from Sjors Provoost to add v0.20.1 to the backwards compatibility test.</p>
<blockquote>
<p>And conversely what backward compatibility testing is done to ensure previous releases pass the current unit and functional tests?</p>
</blockquote>
<p>I don't know at this stage if this in any way a priority (or for that matter whether it should be). It is certainly more resource intensive to build entire previous releases and then test them rather than merely spin up functional test nodes from previous releases. (I will update if I learn more.)</p>

CC BY-SA 4.0
2020-12-30T12:34:19.417Z
2020-12-30T17:57:35.643Z
2020-12-30T17:57:35.643Z
Michael Folkson
<p>The unit and functional tests of the latest release of Bitcoin Core obviously test the codebase of that release.</p>
<p>What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the unit and functional tests?</p>
<p>And conversely what backward compatibility testing is done to ensure previous releases pass the current unit and functional tests?</p>

CC BY-SA 4.0
2020-12-30T14:20:14.537Z
There's no need for a new release to pass functional tests of the old release. However nodes should be compatible when they connect to older versions via the peer to peer network. Currently this testing is pretty limited, see your own answer. In addition, it should be possible to upgrade a node on your own computer, so it should be able to read old (block, mempool, etc) files. Ideally a downgrade should also work.
Sjors Provoost
CC BY-SA 4.0
2020-12-30T14:37:37.547Z
Thanks for this Sjors. In an imaginary world of unlimited resources and testers it is possible (if unlikely) that bug(s) could be caught by running a new release against functional tests of old release? I get it is pretty low on the list of priorities.
Michael Folkson
CC BY-SA 4.0
2020-12-31T15:34:05.097Z
The problem is that each release has changes and the tests are updated to reflect those changes.
Sjors Provoost
<bitcoin-core-development><functional-test><unit-test>
What backward compatibility testing is done on Bitcoin Core?
Michael Folkson
# What backward compatibility testing is done on Bitcoin Core?

(Asked by: username_0 on 2020-12-30)

The unit and functional tests of the latest release of Bitcoin Core obviously test the codebase of that release.

What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the unit and functional tests?

And conversely what backward compatibility testing is done to ensure previous releases pass the current unit and functional tests?

**Tags:** bitcoin-core-development, functional-test, unit-test

> **Comments:**
> **username_1**: There's no need for a new release to pass functional tests of the old release. However nodes should be compatible when they connect to older versions via the peer to peer network. Currently this testing is pretty limited, see your own answer. In addition, it should be possible to upgrade a node on your own computer, so it should be able to read old (block, mempool, etc) files. Ideally a downgrade should also work.  
> **username_0**: Thanks for this Sjors. In an imaginary world of unlimited resources and testers it is possible (if unlikely) that bug(s) could be caught by running a new release against functional tests of old release? I get it is pretty low on the list of priorities.  
> **username_1**: The problem is that each release has changes and the tests are updated to reflect those changes.  

---

## 1 answers

### Answer by username_0 on 2020-12-30. Score: 1 | Accepted answer

> What backward compatibility testing is done to ensure the latest release passes previous releases' versions of the functional tests?

There is a [feature\_backwards\_compatibility.py](https://github.com/bitcoin/bitcoin/blob/master/test/functional/feature_backwards_compatibility.py) functional test which spins up functional test nodes from each of the previous releases to do testing between them at the same time.

Once you have built the latest version of Bitcoin Core you can download the previous release binaries using:

`test/get_previous_releases.py -b v0.19.1 v0.18.1 v0.17.2 v0.16.3 v0.15.2`

You can then run the `feature_backwards_compatibility.py` test individually or through the test runner.

e.g. `test/functional/test_runner.py feature_backwards_compatibility.py`

This test is updated with each new release to add a functional test node from the latest release to functional test nodes from previous releases.

At the time of writing (December 2020) there is an open [pull request](https://github.com/bitcoin/bitcoin/pull/19013) from username_1 to add v0.20.1 to the backwards compatibility test.

> And conversely what backward compatibility testing is done to ensure previous releases pass the current unit and functional tests?

I don't know at this stage if this in any way a priority (or for that matter whether it should be). It is certainly more resource intensive to build entire previous releases and then test them rather than merely spin up functional test nodes from previous releases. (I will update if I learn more.)


---

