Open Stack

Until now we have encouraged project teams to prepare their own
library releases as new versions of projects were needed. We've
started running into a couple of problems with that, with releases
not coming often enough, or at a bad time in the release cycle, or
with version numbering not being applied consistently, or without
proper announcements. To address these issues, the release management
team is proposing to create a small team of library release managers
to handle the process around all library releases (clients,
non-application projects, middleware, Oslo libraries, etc.). This
will give us a chance to collaborate and review the version numbers
for new releases, as well as stay on top of "stale" libraries with
fixes or features that sit unreleased for a period of time. It will
also be the first step to creating an automated review process for
release tags.

The process still needs to be worked out, but I envision it working
something like this:

The release liaison/PTL for the project team submits a request for
a new release, including the repo name, the SHA, the series (liberty,
kilo, etc.), and the proposed version number. The release team
checks the proposed version number against the unreleased changes
up to that SHA, and then either updates it to reflect semver or
uses it as it is provided. The release team would then handle the
tag push and the resulting announcements.

There would be a few conditions under which a new release might not
be immediately approved, but really only when the gate is wedged
and during freeze periods. The point of the change isn't to block
releases, just ensure consistency and good timing.

We have some tools to let us look for unreleased changes, and
eventually we can set up a recurring job to build that report so
we can propose releases to project teams with a large release
backlog. That will likely come later, though.

We can also pre-announce proposed releases if folks find that useful.

We will need a small number of volunteers to join this team, and
start building the required expertise in understanding the overall
state of the project, and in semantic versioning. We do not necessarily
want a liaison from every project -- think of this as the proto-team
for the group that eventually has core reviewer rights on the release
automation repository.

Doug