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. --John On 9 Aug 2016, at 9:24, Ian Cordasco wrote: > > > -----Original Message----- > From: Sean Dague <[email protected]> > Reply: OpenStack Development Mailing List (not for usage questions) > <[email protected]> > Date: August 9, 2016 at 11:21:47 > To: [email protected] <[email protected]> > Subject: Re: [openstack-dev] [requirements] History lesson please > >> On 08/09/2016 11:25 AM, Matthew Thode wrote: >>> On 08/09/2016 10:22 AM, Ian Cordasco wrote: >>>> -----Original Message----- >>>> From: Matthew Thode >>>> Reply: [email protected] , OpenStack Development >> Mailing List (not for usage questions) >>>> Date: August 9, 2016 at 09:53:53 >>>> To: [email protected] >>>> Subject: Re: [openstack-dev] [requirements] History lesson please >>>> >>>>> One of the things on our todo list is to test the 'lower-constraints' to >>>>> make sure they still work with the head of branch. >>>> >>>> That's not sufficient. You need to find versions in between the lowest >>>> tested version >> and the current version to also make sure you don't end up with breakage. >> You might have >> somepackage that has a lower version of 2.0.1 and a current constraint of >> 2.12.3. You >> might even have a blacklist of versions in between those two versions, but >> you still need >> other versions to ensure that things in between those continue to work. >>>> >>>> THe tiniest of accidental incompatibilities can cause some of the most >>>> bizarre bugs. >>>> >>>> -- >>>> Ian Cordasco >>>> >>> >>> I'm aware of this, but this would be a good start. >> >> And, more importantly, assuming that testing is only valid if it covers >> every scenario, sets the bar at entirely the wrong place. >> >> A lower bound test would eliminate some of the worst fiction we've got. >> Testing is never 100%. With a complex system like OpenStack, it's >> probably not even 1% (of configs matrix for sure). But picking some >> interesting representative scenarios and seeing that it's not completely >> busted is worth while. > > Right. I'm not advocating for testing every released version of a dependency. > In general, it's good to test versions that have *triggered* changes though. > If upgrading from 2.3.0 to 2.4.1 caused you to need to fix something, test > something earlier than 2.4.1, and 2.4.1, and then something later. That's > what I'm advocating for. > > -- > Ian Cordasco > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
