[openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

Kyle Mestery mestery at mestery.com
Fri Feb 5 17:05:53 UTC 2016

On Fri, Feb 5, 2016 at 10:50 AM, John Belamaric <jbelamaric at infoblox.com> wrote:
> Hi all,
> Back in November, there was a discussion [1] on the mailing list around release:independent projects, which was wrapped up by Thierry in [2]. However, I have a couple lingering questions that have come up.
> In networking-infoblox, we have a 1.0.0 version of our driver that we released a few months ago, and it is maintained in a the stable/liberty branch. We just released 2.0.0 out of master, but 2.0.0 is compatible with Liberty and Mitaka. So, from a branching perspective, is it permissible to push all the 2.0.0 changes into stable/liberty? Those would be largely functional changes, not simple bug fixes. If not, should we even *have* a stable/liberty branch?
If you're in the Neutron Stadium, and thus following OpenStack stable
backport rules, you cannot backport functional features like you want.
If you remove yourself from the stadium, you don't have that issue and
can backport whatever you want to whatever branch you want. This is
why for some vendor networking sub-projects it may make more sense to
be outside the stadium, because it would align with how you want to do
your own releases.

> The primary reason this is important is to ensure that users and distributors pull the correct version of the driver. The 1.0.0 version is pretty limited and we definitely want the 2.0.0 to be the one packaged with Liberty distributions. So, ideally we would be able to push all the 2.0.0 code into stable/liberty since it is completely compatible - that would make it simple for distributors to get the right driver.
> John
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78676
> [2] http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list