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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev