aboutsummaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
authorxmr-eric <eric@moneroeric.com>2017-12-05 15:42:23 -0500
committerxmr-eric <eric@moneroeric.com>2017-12-07 18:12:19 -0500
commit41fc11fab340e6a37149e7ae9a7a5fd709fca124 (patch)
treeb16b6f0504aad37e8fad5ce1919bbe9c64673af2 /README.md
parentKeep VRP a proper noun (diff)
downloadmonero-41fc11fab340e6a37149e7ae9a7a5fd709fca124.tar.xz
Scheduled mandatory software upgrades
Diffstat (limited to '')
-rw-r--r--README.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/README.md b/README.md
index 5c4f2ae51..c2eacc9bd 100644
--- a/README.md
+++ b/README.md
@@ -90,13 +90,13 @@ See [LICENSE](LICENSE).
If you want to help out, see [CONTRIBUTING](CONTRIBUTING.md) for a set of guidelines.
-## Network consensus protocol upgrades (hard fork schedule)
+## Scheduled mandatory software upgrades
-Monero uses a fixed-schedule network consensus protocol upgrade (hard fork) mechanism to implement new features. This means that users of Monero (end users and service providers) need to run current versions and upgrade their software on a regular schedule. Network consensus protocol upgrades occur during the months of March and September. Required software for these consensus protocol upgrades is available prior to the date of the consensus protocol upgrade. Please check the git repository prior to this date for the proper Monero software version. Below is the historical schedule and the projected schedule for the next upgrade.
+Monero uses a fixed-schedule mandatory software upgrade (hard fork) mechanism to implement new features. This means that users of Monero (end users and service providers) need to run current versions and upgrade their software on a regular schedule. Mandatory software upgrades occur during the months of March and September. The required software for these upgrades will be available prior to the scheduled date. Please check the repository prior to this date for the proper Monero software version. Below is the historical schedule and the projected schedule for the next upgrade.
Dates are provided in the format YYYY-MM-DD.
-| Consensus upgrade block height | Date | Consensus version | Minimum Monero version | Recommended Monero version | Details |
+| Software upgrade block height | Date | Fork version | Minimum Monero version | Recommended Monero version | Details |
| ------------------------------ | -----------| ----------------- | ---------------------- | -------------------------- | ---------------------------------------------------------------------------------- |
| 1009827 | 2016-03-22 | v2 | v0.9.4 | v0.9.4 | Allow only >= ringsize 3, blocktime = 120 seconds, fee-free blocksize 60 kb |
| 1141317 | 2016-09-21 | v3 | v0.9.4 | v0.10.0 | Splits coinbase into denominations |
@@ -109,7 +109,7 @@ X's indicate that these details have not been determined as of commit date, 2017
## Release staging schedule and protocol
-Approximately 3 months prior to a network consensus protocol upgrade, a branch from Master will be created with the new release version tag. Pull requests that address bugs should then be made to both Master and the new release branch. Pull requests that require extensive review and testing (generally, optimizations and new features) should *not* be made to the release branch.
+Approximately three months prior to a scheduled mandatory software upgrade, a branch from Master will be created with the new release version tag. Pull requests that address bugs should then be made to both Master and the new release branch. Pull requests that require extensive review and testing (generally, optimizations and new features) should *not* be made to the release branch.
## Installing Monero from a package