-----Original Message----- From: John Dickinson <m...@not.mn> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Date: August 9, 2016 at 13:17:08 To: OpenStack Development Mailing List <openstack-dev@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. -- Ian Cordasco __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
