Documenting the OpenStack release new identification process

After the discussion in ML thread[1], gerrit[2], Foundation
staff joined in TC meeting and we all agreed to give the release
name handling to Foundation and TC will not be involved in that[3].

Release name will be used for marketing purpose and release tooling
but we will use the release number as a primary identifier in the
OpenStack development cycle. TC had another call[4] to discuss about
the details of where to use releae name and number and passed the
resolution
- https://review.opendev.org/c/openstack/governance/+/843214

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028354.html
[2] https://review.opendev.org/c/openstack/governance/+/839897
[3] https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-12-15.00.log.html#l-245
[4] https://etherpad.opendev.org/p/openstack-release-identification-schema

Change-Id: Ibeb66662e7b71c3b7b1c1acee3bfccfcca11e544
This commit is contained in:
Ghanshyam Mann 2022-05-25 17:10:58 -05:00
parent 36ff562d31
commit d29da1b7de
1 changed files with 33 additions and 50 deletions

View File

@ -13,7 +13,7 @@ Example:
* OpenStack 2023.1 Axxxx
Where "2023" is the year of the release, "1" represents the first release
of the year and "Axxxx" is the release name following the release name rules.
of the year and "Axxxx" is the release name.
Other examples:
@ -24,64 +24,44 @@ With this release identification schema we get an easy and sustainable
approach to identify different OpenStack releases without dealing with the
ambiguity of the release name and alphabet iteration.
The release identification schema doesn't replace the release name.
It's just an unambiguous way to identify OpenStack releases.
The OpenStack Technical Committee has passed a :doc:`resolution
<../resolutions/20220524-release-identification-process>` for the release
identification process. The release number will be used as the primary
identifier in the development cycle but the release name will also be used
in some places.
* Stable branches: Use release number for stable branch name.
Example: stable/2023.1
* Spec repo or any other directory structure: Use release number which is more
aligned with what stable branches are going to use.
* Testing tools: Use release number which is more aligned with what stable
branches are going to use.
* Release page/tooling/milestone name: The release team can choose either to
continue using the release name or use number for release tooling and
milestone name.
Release Name
------------
Each OpenStack development cycle has a code-name that is
proposed and chosen by the community. This name is frequently used in
preference to version numbers to refer to the release at the end of
the cycle. The process of choosing the name should be an enjoyable
activity for the community to mark the software development cycle, and
the name itself should be fun to use.
We will continue with the release name but mainly for marketing usage.
Because the name will become associated with OpenStack, and a
particular release, the process should consider potential issues of
trademark.
* OpenStack release names will be handled by the staff of the OpenInfra
Foundation.
Release Naming Process
----------------------
* Foundation staff will define the naming criteria and process but make sure
they satisfy the OpenStack release team's tooling requirements.
#. Anyone may propose a name that matches the `Release Name
Criteria`_. Proposed names should be added to a page on the
OpenStack wiki.
* The OpenStack release team PTL sign-off is needed on naming criteria defined
by the Foundation staff.
#. A Condorcet election is held to rank the names. The electorate will be
Technical Committee, and the poll should be run in a manner that allows
members of the community to see what each TC member voted for.
* The OpenStack Technical Committee will not be involved in the process,
the release team will directly coordinate with the foundation staff.
#. The Foundation will perform a trademark check on the winning name.
If there is a trademark conflict, then the Foundation will proceed
down the ranked list of Condorcet results until a name without a
trademark conflict is found. This will be the selected name.
Release Name Criteria
---------------------
The following rules are designed to provide some consistency in the
pattern used to select release names, provide a fun challenge in
finding names that meet the criteria, and prevent unwieldy names from
being chosen.
#. Each release name must start with the letter of the ISO basic Latin
alphabet following the initial letter of the previous release,
starting with the initial release of "Austin". After "Z", the next
name should start with "A" again.
#. A release name can't be repeated between different iterations of the
alphabet.
#. The name must be composed only of the 26 characters of the ISO
basic Latin alphabet. Names which can be transliterated into this
character set are also acceptable.
#. The name must be a single word with a maximum length of 10 characters.
Polls
-----
Release Name Selection History
------------------------------
======= ============== ================ ========== ========== ==================
Release Coordinator Nominations Open Poll Open Poll Close Geographic Region
@ -102,6 +82,9 @@ Y_ Ghanshyam Mann 2021-05-13 2021-06-10 2021-06-17 N/A
Z_ Ghanshyam Mann 2022-01-11 2022-01-25 2022-02-01 N/A
======= ============== ================ ========== ========== ==================
The Zed release is the last release for which the OpenStack Technical Committee
was involved in the selection of the release name.
.. [*] Starting with the W release, the naming criteria changed from referring
to the physical or human geography of the region encompassing the location
of the OpenStack Summit, to any name proposed by the community that starts