Since the responsibility for releases will move between people, we document that process here.
A full list of projects that ironic manages is available in the governance site.
The current PTL is ultimately responsible for making sure code gets released. They may choose to delegate this responsibility to a liaison, which is documented in the cross-project liaison wiki.
Anyone may submit a release request per the process below, but the PTL or liaison must +1 the request for it to be processed.
Releases are managed by the OpenStack release team. The release process is documented in the Project Team Guide.
The ironic project has a number of deliverables under its governance. The ultimate source of truth for this is projects.yaml in the governance repository. These deliverables have varying release models, and these are defined in the deliverables YAML files in the releases repository.
In general, ironic deliverables follow the cycle-with-intermediary release model.
The following deliverables are non-client libraries:
The following deliverables are client libraries:
The following deliverables are Neutron plugins:
The following deliverables are Horizon plugins:
The following deliverables are Tempest plugins:
The following deliverables are services, or treated as such:
The following deliverables are released independently:
The following deliverables do not need to be released:
Review the unreleased release notes, if the project uses them. Make sure they follow our standards, are coherent, and have proper grammar. Combine release notes if necessary (for example, a release note for a feature and another release note to add to that feature may be combined).
For ironic releases only, not ironic-inspector releases: if any new API
microversions have been added since the last release, update the REST API
version history (doc/source/contributor/webapi-version-history.rst
) to
indicate that they were part of the new release.
To support rolling upgrades, add this new release version (and release name
if it is a named release) into ironic/common/release_mappings.py
:
in RELEASE_MAPPING
make a copy of the master
entry, and rename the
first master
entry to the new semver release version.
If this is a named release, add a RELEASE_MAPPING
entry for the named
release. Its value should be the same as that of the latest semver one
(that you just added above).
It is important to do this before a stable/<release> branch is made (or if the grenade switch is made to use the latest release from stable as the ‘old’ release). Otherwise, once it is made, CI (the grenade job that tests new-release -> master) will fail.
When a release is done that results in a stable branch for the project, several changes need to be made.
The release automation will push a number of changes that need to be approved. This includes:
In the new stable branch:
.gitreview
at the branchtox
In the master branch:
updating the release notes RST to include the new branch.
The generated RST does not include the version range in the title, so we typically submit a follow-up patch to do that. An example of this patch is here.
update the templates in .zuul.yaml or zuul.d/project.yaml.
The update is necessary to use the job for the next release openstack-python3-<next_release>-jobs. An example of this patch is here.
We need to submit patches for changes in the stable branch to:
ironic/doc/source/
) to point to the
branched versions of any openstack projects’ (that branch) documents.
As of Pike release, the only outlier is
diskimage-builder.TEMPEST_BAREMETAL_MIN_MICROVERSION
and
TEMPEST_BAREMETAL_MAX_MICROVERSION
in devstack/lib/ironic
to make sure
that unsupported API tempest tests are skipped on stable branches. E.g.
patch 495319.We need to submit patches for changes on master to:
Sem-Ver
tag to bump the generated minor
version. See example
and pbr documentation for details.ironic/common/release_mappings.py
, delete any entries from
RELEASE_MAPPING
associated with the oldest named release. Since we
support upgrades between adjacent named releases, the master branch will
only support upgrades from the most recent named release to master.ironic.cmd.dbsync.ONLINE_MIGRATIONS
and remove the corresponding code from ironic. (These migration scripts
are used to migrate from an old release to this latest release; they
shouldn’t be needed after that.)ironic.cmd.dbsync.NEW_MODELS
.As ironic-tempest-plugin is branchless, we need to submit a patch adding stable jobs to its master branch. Example for Queens.
For all releases, whether or not it results in a stable branch:
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.