[36pt] Update release policy web page

[kyukhin]

Let's reflect the reality.

This update should go to all branches.

1. Remove this sentence: "We use these digits according to their definitions provided at http://semver.org"

2. "In MINOR digit, we reflect how stable a release is:" -> "In PATCH digit, we reflect how stable a release is:"

3. "anything between 1 and 10 meaning stable, and" -> "anything above 2 meaning stable, and"

4. "10 meaning LTS." -> (null)

5. "So, each MAJOR release series goes through a development-maturity life cycle of MINOR releases, as follows:" -> "So, each MINOR release series goes through a development-maturity life cycle, as follows:"

6. "Alpha. Once in every few months we release a few alpha versions, e.g. 2.4.0, 2.5.0." ->
   "Alpha. Once a quarter we start off new Alpha version. This is not what classic alpha but rather current trunk version which is under heavy development and may be unstable. Current alpha version always live in the master branch."

7. "Beta. Once all planned features are implemented we fork a new branch from the master and tag it as new beta version. It contains 1 for PATCH. e.g. 2.4.1, 2.5.1. This version is still unstable although there're no critical regressions since a last stable release in it. We do that quarterly as well."

8. "Stable. Finally, after we see our beta versions run successfully in production, usually in a few more months, during which we fix all incoming bugs and add some minor features, we declare this MAJOR release series stable." -> "Stable. Finally, after we see our beta versions run successfully in production or in development environment during another quarter while we fix incoming bugs we declare version as stable. It is tagged w/ 2 for PATCH. E.g. 2.4.2, 2.5.2. We support such version for 3 months making another stable release after a quarter w/ fixes of all bugs found. This last tag on the release branch contains 3 for PATCH. E.g. 2.4.3, 2.5.3. After the tag is put, no new changes are allowed to the release branch and it is declared deprecated and superseded by newer version."

9. "LTS (Long Term Support) releases that are supported for 3 years (community) and up to 5 years (paying customers). LTS release is identified by MINOR version 10." -> "LTS (Long Term Support) releases that are supported for 3 years (community) and up to 5 years (paying customers). LTS release is currently 1.10.x"

10. "We add commits simultaneously to three MAJOR releases:" -> "We add bug fixes simultaneously in three releases and alpha:"

11. "Hence, following the rules of semver, LTS release never has its MAJOR or MINOR version increased, and only gets PATCH level releases." -> "LTS release never has its MAJOR or MINOR version increased, and only gets PATCH level releases."

12. "STABLE is our current stable release, which may receive new features. When the next STABLE version is published, MINOR version is incremented. Between MINOR releases, we may have intermediate PATCH level releases as well, which will contain only bug fixes. We maintain PATCH level releases for two STABLE releases, the current and the previous one, to preserve support continuity." -> "STABLE[S] are our current stable releases, which may not receive new features. When the next STABLE version is published, MINOR version is incremented. We maintain PATCH level releases for two STABLE releases, the current and the previous one, to preserve support continuity."

13. "NEXT is our next MAJOR release, and it follows the maturity cycle described in the beginning. While NEXT release is in alpha state, its MINOR is frozen at 0 and is only increased when the release reaches BETA status. Once the NEXT release becomes STABLE, we switch the vehicle for delivery of minor features, designating the previous stable release as LTS, and releasing it with MINOR set to 10." -> "BETA is our next MINOR release, and it follows the maturity cycle described in the beginning."

14. "the next LTS release, e.g. 2.10.6, 2.10.7 or 2.10.8" -> "the next LTS release, e.g. 1.10.6, 1.10.7 or 1.10.8"

15. "the next STABLE release, e.g. 3.6, 3.7 or 3.8" -> "the next STABLE releases, e.g. 2.4.2, or 2.3.3"

16. "(optionally) an alpha or beta version of the NEXT release, e.g. 4.0.1, 4.0.2 or 4.0.3" -> "A beta version of the NEXT release, e.g. 2.5.1 or 2.6.1"

17. "2.0.3 - third alpha of 2.x release" -> "2.5.0 - current alpha version under development"

18. "2.1.3 - a beta of 2.x release" -> "2.6.1 - a beta of 2.6 release"

19. "2.2 - a stable version of 2.x series, but not an LTS yet" -> "2.2.3 or 2.4.2 - a stable version of 2.2 or 2.4 series, but not an LTS yet"

20. "2.10 - an LTS release" -> "1.10.8 - an LTS release"

[kyukhin]

And please fix my Chinese English.

[Totktonada]

I would also propose to list all releases since 1.10.0 in a table with four columns: alpha, beta, stable, TLS. So it will be easy for a user to find a version and understand its status without reading the whole policy.

[lenkis]

Still undecided whether to put this into the manual https://www.tarantool.io/en/doc/2.3/dev_guide/release_management/

or as a standalone page within the site, somewhere at https://www.tarantool.io/en/download/

Waiting for decision from @artur-barsegyan

UPD: approved with @zaraysky and @LapaevPavel to put this as a standalone page linked from the Downloads page

[kyukhin]

What I need to say is that this page does not correspond reality https://www.tarantool.io/en/doc/1.10/dev_guide/release_management/

(for all versions)