The answers are it's possible to use old versions because if you have private keys, you have coins. It is recommended to upgrade to newest versions if you are running business with Bitcoin payments, use scripts ...
The most recent version is the version the foremost experts on the software think you ought to be running, otherwise it wouldn't exist. So unless you've got a really good reason to do otherwise, that's what you ought to be running.
Revisions of old major numbers are primarily useful for parties that are carrying patches against their nodes or require qualification for new versions that might have changed behavior in incompatible ways, so that they can more rapidly deploy fixes. It might take them longer to forward port their patches to the new major version or to test it against their usage. If you're in one of those situations you'll know it.
Revisions of old major numbers are primarily useful for parties that are carrying patches against their nodes or require qualification for new versions that might have changed behavior in incompatible ways, so that they can more rapidly deploy fixes. It might take them longer to forward port their patches to the new major version or to test it against their usage. If you're in one of those situations you'll know it.
I find answers on Bitcoin Core website too.
Software Life Cycle
Please read the Maintenance Period and Schedule table if you are wondering should upgrade your Bitcoin Core wallet.
Quote
Software Life Cycle
This document describes the life-cycle of the Bitcoin Core software package released by the Bitcoin Core project. It is in line with standard maintenance policy across commercial software.
Major releases
We aim to make a major release every 6-7 months.
These will be numbered 22.0, 23.0 etc.
Maintenance releases
We will provide maintenance “minor releases” that fix bugs within the major releases. As a general rule we do not introduce major new features in a maintenance release (except for consensus rules). However, we may add minor features where necessary, and we will back-port consensus rule changes such as soft forks.
Minor releases will be numbered 22.1, 22.2, 23.1, 23.2 etc.
Maintenance period
We maintain the major versions until their “Maintenance End”. We generally maintain the current and previous major release. For example, if the current release is 23.0, then 22.0 is also considered maintained. Once 24.0 is released, then 22.0 would be considered at its “Maintenance End”. As a major release ages, issues have to be increasingly critical to be backported to it, and an increasing amount or severity of issues is required to warrant a new minor release. Once software has reached the “Maintenance End” period, it will only receive critical security fixes until the End-of-Life (EOL) date. After EOL, users must upgrade to a later version to receive security updates, even though the community may provide fixes for critical issues on a best effort basis. Generally, it is recommended to run the latest maintenance release (point release) of the current or previous major version.
Please note that minor versions get bugfixes, translation updates, and soft forks. Translation on Transifex is only open for the last two major releases.
For example, major version 22.0 was released on 2021-09-13 and we provided maintenance fixes (point releases) until 2022-11-15. Critical security issues would still be continued to be fixed until the EOL date of 2024-04-01. However, to take advantage of bug fixes, you would have to upgrade to a later major version.
Schedule
Once EOL is reached, you will need to upgrade to a newer version.
* We aim to make a major release every 6-7 months
TBA: to be announced
This document describes the life-cycle of the Bitcoin Core software package released by the Bitcoin Core project. It is in line with standard maintenance policy across commercial software.
Major releases
We aim to make a major release every 6-7 months.
These will be numbered 22.0, 23.0 etc.
Maintenance releases
We will provide maintenance “minor releases” that fix bugs within the major releases. As a general rule we do not introduce major new features in a maintenance release (except for consensus rules). However, we may add minor features where necessary, and we will back-port consensus rule changes such as soft forks.
Minor releases will be numbered 22.1, 22.2, 23.1, 23.2 etc.
Maintenance period
We maintain the major versions until their “Maintenance End”. We generally maintain the current and previous major release. For example, if the current release is 23.0, then 22.0 is also considered maintained. Once 24.0 is released, then 22.0 would be considered at its “Maintenance End”. As a major release ages, issues have to be increasingly critical to be backported to it, and an increasing amount or severity of issues is required to warrant a new minor release. Once software has reached the “Maintenance End” period, it will only receive critical security fixes until the End-of-Life (EOL) date. After EOL, users must upgrade to a later version to receive security updates, even though the community may provide fixes for critical issues on a best effort basis. Generally, it is recommended to run the latest maintenance release (point release) of the current or previous major version.
Please note that minor versions get bugfixes, translation updates, and soft forks. Translation on Transifex is only open for the last two major releases.
For example, major version 22.0 was released on 2021-09-13 and we provided maintenance fixes (point releases) until 2022-11-15. Critical security issues would still be continued to be fixed until the EOL date of 2024-04-01. However, to take advantage of bug fixes, you would have to upgrade to a later major version.
Schedule
Once EOL is reached, you will need to upgrade to a newer version.
| Version | Release date | Maintenance End | End of life |
| _________ | ______________ | ___________________ | _________________ |
| 28.x | TBA* | after v30.0 | after v31.0 |
| 27.x | 2024-04-16 | after v29.0 | after v30.0 |
| 26.x | 2023-12-06 | after v28.0 | after v29.0 |
| 25.x | 2023-05-18 | 2024-04-16 | after v28.0 |
| 24.x | 2022-11-24 | 2023-12-12 | 2024-04-02 |
| 23.x | 2022-04-25 | 2023-05-18 | 2023-12-01 |
| 22.x | 2021-09-13 | 2022-11-24 | 2023-04-01 |
| 0.21.x | 2021-01-15 | 2022-04-25 | 2022-10-01 |
| 0.20.x | 2020-06-03 | 2021-09-13 | 2022-02-01 |
| 0.19.x | 2019-11-24 | 2021-01-15 | 2021-08-01 |
| 0.18.x | 2019-05-02 | 2020-06-03 | 2021-02-01 |
| 0.17.x | 2018-10-03 | 2019-11-24 | 2020-08-01 |
| 0.16.x | 2018-02-26 | 2019-05-02 | 2020-02-01 |
| 0.15.x | 2017-09-15 | 2018-10-03 | 2019-08-01 |
| 0.14.x | 2017-03-08 | 2018-02-26 | 2019-02-01 |
| 0.13.x | 2016-08-23 | 2017-09-15 | 2018-08-01 |
| 0.12.x | 2016-02-23 | 2017-03-31 | 2018-02-28 |
| 0.11.x | 2015-07-12 | 2016-08-23 | 2017-08-01 |
| 0.10.x | 2015-02-16 | 2016-02-29 | 2017-02-28 |
| 0.9.x | 2014-03-19 | 2015-06-16 | 2016-02-28 |
| 0.8.x | 2013-02-19 | 2014-03-19 | 2015-12-31 |
| _________ | ______________ | ___________________ | _________________ |
TBA: to be announced
And more to read on that page.