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

Akihiro Motoki amotoki at gmail.com
Fri Feb 5 17:18:40 UTC 2016


I don't think you need to bump the major version per OpenStack release.
If the functionalities is backward-compatible, from the context of the
semantic versioning
you don't need to bump the major version, i.e. 1.x.y to 2.x.y.
According to your description, Mitaka version can be 1.1.0.
I am not sure we need to bump the major version in every OpenStack
release in neutron sub-projects.

As Kyle said, it is important to follow the stable backport policy of course :-)

Akihiro

2016-02-06 2:05 GMT+09:00 Kyle Mestery <mestery at mestery.com>:
> 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
>
> __________________________________________________________________________
> 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