Open Stack

On 9 Aug 2016, at 11:33, Ian Cordasco wrote:

>  
>
> -----Original Message-----
> From: John Dickinson <me at not.mn>
> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> Date: August 9, 2016 at 13:17:08
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [requirements] History lesson please
>
>> I'd like to advocate for *not* raising minimum versions very often. Every time some OpenStack
>> project raises minimum versions, this change is propagated to all projects, and that
>> puts extra burden on anyone who is maintaining packages and dependencies in their own
>> deployment. If one project needs a new feature introduced in version 32, but another
>> project claims compatibility with >=28, that's ok. There's no need for the second project
>> to raise the minimum version when there isn't a conflict. (This is the position I advocated
>> for at the Austin summit.)
>>
>> Yes, I know that currently we don't test every possible version permutation. Yes, I know
>> that doing that is hard. I'm not ignoring that.
>
> Right. So with the current set-up, where these requirements are propogated to every project, how do projects express their own minimum version requirement?
>
> Let's assume someone is maintaining their own packages and dependencies. If (for example) Glance requires a minimum version of Routes and Nova has a minimum requirement newer than Glance's, they're not coinstallable (which was the original goal of the requirements team). What you're asking for ends up being "Don't rely on new features in a dependency". If OpenStack drops the illusion of coinstallability that ends up being fine. I don't think anyone wants to drop that though.

In that case, they are still co-installable, because the nova minimum satisfies both.

>
> --
> Ian Cordasco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160809/5535e235/attachment.pgp>