[openstack-dev] [TripleO][release] TripleO Newton Release schedule and Feature Freeze

Steven Hardy shardy at redhat.com
Fri Jul 15 09:18:43 UTC 2016


Hi all,

So we discussed $subject in our weekly meeting, and I wanted to follow up
with some proposals to clarify our plan wrt the final Newton release,
feature freeze, and how the dates will line up given that we're now
following[1] the cycle-trailing release model[2] for most TripleO
deliverables.

According to the official release schedule[3], the feature freeze for
most projects is aligned with the newton-3 milestone (August 29th) - I
suggest that we observe the same date for our Feature Freeze, but that we
also observe the normal process for feature freeze exceptions.

This means that we'll have a "release valve" in the event that we require
feature-orientated changes to TripleO near the end of the cycle
(integrating a new service that's disabled by default was mentioned as an
example in the meeting), but also that we'll enable greater control over
the nature of changes that are accepted towards the end of the cycle.

Note that the process is to email this list, with a description of the FFE
that is required, and a justification of why it's needed and low-risk.
We'll then discuss it and vote to accept or deny it (the closer we get to
the release the more likely we are to deny any exceptions due to the risk
of regressions).

Nearer the time I'll create RC milestones, which we can use to track
incremental releases (containing post newton-3 bugfixes and FFE features)
as we work towards our Newton final release.

After the main Newton coordinated release (planned for October 3rd) no feature
backports will be permitted, and we'll ship the TripleO final release
before the cycle-trailing deadline (October 17th, hopefully we'll release
sooner than that though provided all the packaging and puppet dependencies
are finished).

Also note that when we cut stable/newton we'll again be observing the
normal stable branch process[5], which means bugfixes only - no feature
backports will be permitted (same as we've done for stable/mitaka).

Hope that makes sense, please let me know if there are any comments,
concerns or questions!

Thanks!

Steve


[1] https://review.openstack.org/#/c/308236/
[2] https://github.com/openstack/governance/blob/master/reference/tags/release_cycle-trailing.rst
[3] http://releases.openstack.org/newton/schedule.html
[4] http://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
[5] http://docs.openstack.org/project-team-guide/stable-branches.html



More information about the OpenStack-dev mailing list