Release management chapter updates
The release management chapter failed to take into account a number of recent policy changes by the Release Team, around available release models, usage of $PROJECT-stable-maint pre-release[1], or handling of all official deliverables[2]. This change updates the chapter to the current state of affairs. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128731.html [2] https://review.openstack.org/#/c/557737/ Change-Id: If45a7577b9ecc88e9a81830c5a4fd9b973a435fc
This commit is contained in:
parent
7d253d1127
commit
b512eaa35f
|
@ -84,12 +84,9 @@ another milestone tagged that includes the latest translations.
|
|||
|
||||
Potential new release critical issues have first to get fixed on the master
|
||||
branch. Once merged in master, they can be backported to the release branch.
|
||||
A specific Gerrit team named PROJECTNAME-release (usually the PTL, release
|
||||
liaison and other few trusted team members) is tasked with approving such
|
||||
backports. To that effect, the PROJECTNAME-release team has CodeReview+2 and
|
||||
Workflow+1 rights on the stable/$series branch until final release. Once all
|
||||
the desired backports (and translations updates) are merged, a new release
|
||||
candidate can be produced.
|
||||
The PROJECTNAME-stable-maint team is tasked with approving such backports.
|
||||
Once all the desired backports (and translations updates) are merged, a new
|
||||
release candidate can be produced.
|
||||
|
||||
On final release day, the Release Team will take each project's last release
|
||||
candidate and re-tag it with the final release version. There is no difference
|
||||
|
@ -126,7 +123,7 @@ of the X.Y.Z version when we switch to the next development cycle, so that the
|
|||
Z component can be used in future tags on the release (or stable) branch.
|
||||
|
||||
While the release management team will not enforce a formal feature-frozen
|
||||
period for projects in an independent release model, it is recommended to
|
||||
period for projects in an intermediary release model, it is recommended to
|
||||
focus on bug fixes and hold on major disruptive features as you get closer
|
||||
to the end of a development cycle, to ensure that the final release of any
|
||||
given development cycle is as usable and bug-free as it can be.
|
||||
|
@ -134,23 +131,23 @@ given development cycle is as usable and bug-free as it can be.
|
|||
Trailing the common cycle
|
||||
-------------------------
|
||||
|
||||
Some projects follow the release cycle, but because they rely on the other
|
||||
projects being completed, they may not always publish their final release at
|
||||
the same time as those projects. For example, projects related to packaging
|
||||
or deploying OpenStack components need the final releases of those components
|
||||
to be available before they can run their own final tests.
|
||||
Deployment and lifecycle-management tools generally want to follow the
|
||||
release cycle, but because they rely on the other projects being completed,
|
||||
they may not always publish their final release at the same time as those
|
||||
projects. To that effect, they may choose the cycle-trailing release model.
|
||||
|
||||
Cycle-trailing projects are given an extra 2 weeks after the final release date
|
||||
to request publication of their release. They may otherwise use intermediary
|
||||
releases or development milestones.
|
||||
Cycle-trailing projects are given an extra 3 months after the final release
|
||||
date to request publication of their release. They may otherwise use
|
||||
intermediary releases or development milestones.
|
||||
|
||||
Independent release model
|
||||
-------------------------
|
||||
|
||||
Deliverables that do not benefit from a coordinated release or from stable
|
||||
branches may opt to follow a completely independent release model.
|
||||
Deliverables that are not part of the main "OpenStack" product release, do
|
||||
not benefit from a coordinated release or from stable branches may opt to
|
||||
follow a completely independent release model.
|
||||
|
||||
Versions are tagged from the master branch without any specific constraint,
|
||||
Releases are made from the master branch without any specific constraint,
|
||||
although the usage of a post-version numbering scheme based on
|
||||
`semantic versioning`_ is strongly recommended.
|
||||
|
||||
|
@ -182,8 +179,8 @@ release is made to minimize the duration of any outage, without
|
|||
requiring extra effort outside of a normal work week by overlapping
|
||||
with the weekend.
|
||||
|
||||
Technically, releases are created by pushing a *signed* tag to the gerrit
|
||||
repository where the library is managed. The CI system recognizes the
|
||||
Technically, releases are created by pushing a *signed* tag to the git
|
||||
repositories associated with that deliverable. The CI system recognizes the
|
||||
new signed tag, and triggers the jobs that build the packages, upload them
|
||||
to the distribution servers (our tarball site and the Python Package Index),
|
||||
and send email announcements.
|
||||
|
@ -194,38 +191,22 @@ releases, see the `Project Creator's Guide`_ from the
|
|||
|
||||
.. _Project Creator's Guide: https://docs.openstack.org/infra/manual/creators.html
|
||||
|
||||
.. _release-process-managed:
|
||||
|
||||
Release process for projects following the release cycle
|
||||
--------------------------------------------------------
|
||||
|
||||
Releases for deliverables following one of the three models tied to the release
|
||||
cycle (cycle-with-milestones, cycle-with-intermediary, and cycle-trailing) are
|
||||
handled by the release team at the request of the PTL or release liaison for
|
||||
the project. Requests should be submitted in the form of a patch to the
|
||||
appropriate "deliverables" file in the ``openstack/releases`` git repository.
|
||||
The tagging and releasing process is error-prone. In order to properly review
|
||||
proposed tags and run tests before the tag is actually pushed, we use a
|
||||
specific repository, ``openstack/releases``, to file release requests.
|
||||
Releases are requested by the PTL or release liaison for the project, in the
|
||||
form of a patch to the appropriate "deliverables" file of that repository.
|
||||
See the `README file in that repository`_ for more details.
|
||||
|
||||
Such requests are then checked and processed by the Release Team, generally
|
||||
avoiding Mondays and Fridays and periods where the CI system is not fully
|
||||
operational.
|
||||
Such requests are then automatically tested, reviewed and processed by the
|
||||
Release Team, generally avoiding Mondays and Fridays and periods where the
|
||||
CI system is not fully operational.
|
||||
|
||||
.. _README file in that repository: http://git.openstack.org/cgit/openstack/releases/tree/README.rst
|
||||
|
||||
Release process for other projects
|
||||
----------------------------------
|
||||
|
||||
OpenStack projects following a cycle-independent model can use the process
|
||||
for projects following the release cycle, or push signed tags by themselves.
|
||||
|
||||
In all cases they should use a variation of `semantic versioning`_ (or SemVer)
|
||||
rules to choose version numbers, and they should push the corresponding patch
|
||||
to the ``openstack/releases`` git repository so that the release appears on
|
||||
the https://releases.openstack.org website.
|
||||
|
||||
.. _semantic versioning: https://docs.openstack.org/pbr/latest/user/semver.html#semantic-versioning-specification-semver
|
||||
|
||||
|
||||
Release Liaisons
|
||||
================
|
||||
|
||||
|
@ -258,8 +239,6 @@ must ensure they are done by someone on the project team.
|
|||
submitted by the liaison or PTL, one of them must indicate their
|
||||
approval.
|
||||
|
||||
See :ref:`release-process-managed` above.
|
||||
|
||||
#. Coordinate feature freeze exceptions (FFEs) at the end of a release
|
||||
cycle (for cycle-with-milestones deliverables), and track blocking
|
||||
bug fixes and feature work that must be completed before a release.
|
||||
|
@ -291,12 +270,10 @@ must ensure they are done by someone on the project team.
|
|||
instructions related to deadlines, release changes that need to be
|
||||
made, etc.
|
||||
|
||||
#. Manage the release-related tags on project deliverables in the
|
||||
project list in the ``openstack/governance`` repository.
|
||||
#. Keep the list of project deliverables (and associated git repositories)
|
||||
in the project team reference list in the ``openstack/governance``
|
||||
repository (``reference/projects.yaml``) up to date.
|
||||
|
||||
Ensure that as new repositories are added to the list managed by
|
||||
each project team, the release model and project type tags are
|
||||
accurate.
|
||||
|
||||
Typical Development Cycle Schedule
|
||||
==================================
|
||||
|
|
Loading…
Reference in New Issue