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 <[email protected]>:
> On Fri, Feb 5, 2016 at 10:50 AM, John Belamaric <[email protected]> 
> 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: [email protected]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [email protected]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to