- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt the
work of the team in a "big tent" world.
One of the key questions there was whether we should continue doing
stable point releases. Those were basically tags with the same version
number ("2015.1.1") that we would periodically push to the stable
branches for all projects.
Those create three problems.
(1) Projects do not all follow the same versioning, so some projects
(like Swift) were not part of the "stable point releases". More and more
projects are considering issuing intermediary releases (like Swift
does), like Ironic. That would result in a variety of version numbers,
and ultimately less and less projects being able to have a common
(2) Producing those costs a non-trivial amount of effort on a very small
team of volunteers, especially with projects caring about stable
branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping them
(3) The resulting "stable point releases" are mostly useless. Stable
branches are supposed to be always usable, and the "released" version
did not undergo significantly more testing. Issuing them actually
discourages people from taking whatever point in stable branches makes
the most sense for them, testing and deploying that.
The suggestion we made during that session (and which was approved by
the session participants) is therefore to just get rid of the "stable
point release" concept altogether for non-libraries. That said:
we'd still do individual point releases for libraries (for critical
bugs and security issues), so that you can still depend on a specific
we'd still very much maintain stable branches (and actually focus our
efforts on that work) to ensure they are a continuous source of safe
upgrades for users of a given series
Now we realize that the cross-section of our community which was present
in that session might not fully represent the consumers of those
artifacts, which is why we expand the discussion on this mailing-list
(and soon on the operators ML).
If you were a consumer of those and will miss them, please explain why.
In particular, please let us know how consuming that version (which was
only made available every n months) is significantly better than picking
your preferred time and get all the current stable branch HEADs at that
Thanks in advance for your feedback,
Thierry Carrez (ttx)
OpenStack Development Mailing List (not for usage questions)