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

>  
>
> -----Original Message-----
> From: John Dickinson <[email protected]>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <[email protected]>
> Date: August 9, 2016 at 13:17:08
> To: OpenStack Development Mailing List <[email protected]>
> 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

Attachment: signature.asc
Description: OpenPGP digital signature

__________________________________________________________________________
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