OpenStack-related libraries¶

Libraries with strong ties with OpenStack are released with a cycle-with-intermediary model, so that:

• they can be released early and often

• services consuming those libraries can take advantage of their new features

• we detect integration bugs early rather than late

This works well while libraries see lots of changes, however it is a bit heavy-handed for feature-complete, stable libraries: it forces those to release multiple times per year even if they have not seen any change.

Once libraries are deemed feature-complete and stable, they should be switched to an independent release model (like all our third-party libraries). Those would see releases purely as needed for the occasional corner case bugfix. They won’t be released early and often, there is no new feature to take advantage of, and new integration bugs should be very rare.

This transition should be definitive in most cases. In rare cases where a library were to need large feature development work again, we’d have two options: develop the new feature in a new library depending on the stable one, or grant an exception and switch it back to the cycle-with-intermediary model.

cycle-trailing¶

The “cycle-trailing” model was 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.

cycle-automatic¶

The “cycle-automatic” model is used by specific technical deliverables that need to be automatically released once at the end of a cycle. Those may, optionally, also be released in the middle of the cycle. Those do not need a stable branch created. This may be applied only to tempest-plugin or other deliverables.

• “cycle-automatic” deliverables will be automatically released by the release team once at the end of a cycle, using the current HEAD of the repository. No stable branch will be automatically created.

• Release tags for deliverables using this model are reviewed and applied by the Release Management team.

cycle-with-milestones¶

The “cycle-with-milestones” model described projects that produced a single release at the end of the cycle, with development milestones published at predetermined times in the cycle schedule.

• “cycle-with-milestones” projects committed 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 committed to produce a release to match the end of the 6-month development cycle.

• Release tags for deliverables using this tag were reviewed and applied by the Release Management team.

• Projects using milestones were expected to tag at least 2 out of the 3 for each cycle, or risk being dropped as an official project. The release team would remind projects that miss the first milestone, and create tags on any later milestones for the project team by tagging HEAD at the time of the deadline. If the release team force-created 2 tags for a project in the same given development cycle, the project would be treated as inactive and the release team would recommend dropping it from the official project list.