doc/releases: remove obsolete info

We haven't done dev releases for years, and versions prior to luminous
are no longer relevant.

Signed-off-by: Josh Durgin <jdurgin@redhat.com>

diff --git a/doc/releases/general.rst b/doc/releases/general.rst
index eff9526fc89d4cc3336b0e37094f58426d5f8017..b7fdbb38738b8697c513ae0853aee3ed2b3f6071 100644 (file)
--- a/doc/releases/general.rst
+++ b/doc/releases/general.rst
@@ -21,34 +21,10 @@ name, since the latin names are harder to remember or pronounce).
 Version numbers have three components, *x.y.z*.  *x* identifies the release
 cycle (e.g., 13 for Mimic).  *y* identifies the release type:
 
-* x.0.z - development releases (for early testers and the brave at heart)
+* x.0.z - development versions
 * x.1.z - release candidates (for test clusters, brave users)
 * x.2.z - stable/bugfix releases (for users)
 
-This versioning convention started with the 9.y.z Infernalis cycle.  Prior to
-that, versions looked with 0.y for development releases and 0.y.z for stable
-series.
-
-Development releases (x.0.z)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Each development release (x.0.z) freezes the master development branch
-and applies `integration and upgrade tests
-<https://github.com/ceph/ceph/tree/master/qa/suites/>`_ before it is released.  Once
-released, there is no effort to backport fixes; developer focus is on
-the next development release which is usually only a few weeks away.
-
-* Development release every 8 to 12 weeks
-* Intended for testing, not production deployments
-* Full integration testing
-* Upgrade testing from the last stable release(s)
-* Every effort is made to allow *offline* upgrades from previous
-  development releases (meaning you can stop all daemons, upgrade, and
-  restart).  No attempt is made to support online rolling upgrades
-  between development releases.  This facilitates deployment of
-  development releases on non-production test clusters without
-  repopulating them with data.
-
 Release candidates (x.1.z)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -98,9 +74,5 @@ For example, Mimic (13.2.z) will reach end of life (EOL) shortly after Octopus
 (15.2.0) is released. The lifetime of a release may vary because it depends on
 how quickly the stable releases are published.
 
-In the case of Jewel and Kraken, the lifetime was slightly different than
-described above. Prior to Luminous, only every other stable release was an "LTS"
-release.
-
 Detailed information on all releases, past and present, can be found at :ref:`ceph-releases-index`