openstack/releases
Code Issues Proposed changes
d690159d48
releases/doc/source/reference/release_models.rst
Thierry Carrez c6f2124ae5 Relax constraints around packaging/lifecycle projects 
There is no reason to impose a short deadline for packaging
or lifecycle management projects that want to trail the
release. Let's relax the constraints and accept that
cycle-trailing releases can happen up to 3 months after the
main components synchronized release.

Additionally, the idea behind the membership check at
milestone-2 is to protect packagers against late additions,
not to prevent late-added packaging systems from doing a
release. The new rules should also apply to Queens, so that
OpenStack-Helm and LOCI can actually do a Queens packaging
release, despite having been added post milestone-2.

Change-Id: If997e6053af6e74bf6ce8755313346effca6b4e5
2018-03-12 17:29:37 +01:00

4.1 KiB
Raw Blame History

Release Models

Development in OpenStack is organized around 6-month cycles (like "kilo"). At the end of every 6-month cycle a number of projects release at the same time, providing a convenient reference point for downstream teams (stable branch maintenance, vulnerability management) and downstream users (in particular packagers of OpenStack distributions).

This "final" release may be the only release of the development cycle, in which case the project publishes intermediary "development milestones" on a time-based schedule during the cycle. Or the project may release more often and make intermediary releases in the middle of the cycle. Other projects trail the main release deadline, waiting for the final releases of components on which they rely.

A given deliverable can't have more than one model. It therefore must choose between one of the following models. A number of rules apply based on what the deliverable is and which bucket of the OpenStack map it falls in:

  • Components appearing in the openstack bucket in the OpenStack map form the main components of an OpenStack cloud, and therefore should follow the release cycle. They need to pick between cycle-with-milestones or cycle-with-intermediary models.
  • Libraries cannot use RCs or trail the release. They need to pick between cycle-with-intermediary and independent release models based on how much they are tied to OpenStack or more generally-useful.
  • Only deployment or lifecycle-management components are allowed to trail the cycle. Therefore only components appearing in the openstack-lifecyclemanagement bucket on the OpenStack map are allowed to use the cycle-trailing model.

cycle-with-milestones

The "cycle-with-milestones" model describes projects that produce a single release at the end of the cycle, with development milestones published at predetermined times in the cycle schedule.

  • "cycle-with-milestones" projects commit to publish development milestones following a predetermined schedule published by the Release Management team before the start of the 6-month cycle.
  • "cycle-with-milestones" projects commit to produce a release to match the end of the 6-month development cycle.
  • Release tags for deliverables using this tag are reviewed and applied by the Release Management team.

cycle-with-intermediary

The "cycle-with-intermediary" model describes projects that produce multiple full releases during the development cycle, with a final release to match the end of the cycle.

  • "cycle-with-intermediary" projects commit to produce a release near the end of the 6-month development cycle to be used with projects using the other cycle-based release models that are required to produce a release at that time.
  • Release tags for deliverables using this tag are reviewed and applied by the Release Management team.

cycle-trailing

The "cycle-trailing" model is used by projects producing OpenStack packaging, installation recipes or lifecycle management tools. Those still do one release for every development cycle, but they can't release until OpenStack itself is released.

  • "cycle-trailing" projects commit to produce a release no later than 3 months after the main release.
  • Release tags for deliverables using this tag are reviewed and applied by the Release Management team.

independent

Some projects opt to completely bypass the 6-month cycle and release independently. For example, that is the case of projects that support the development infrastructure. The "independent" model describes such projects.

  • "independent" projects produce releases from time to time.
  • Release tags for deliverables using this tag are managed without oversight from the Release Management team.

untagged

Some CI tools are used only from source and never tag releases, but need to create stable branches.