But I do think running a job with lowest version may still help a developer realize that a feature in the latest library is not available in an older supported version. The person can then bump up the library's min version in the requirements. Today, it;s not possible to find this out until someone else runs into an issue with the older lib.
Ref:- I have noticed some bugs in the past and I did post about this to openstack-infra. From Jeremy Stanley's comment on that thread, I understand that it may be tough to setup it up this way due to transitive dependencies. -Sabari On Feb 20, 2014, at 3:06 PM, Sean Dague wrote: > On 02/20/2014 05:50 PM, Christopher Yeoh wrote: >> On Thu, 20 Feb 2014 14:45:03 -0500 >> Sean Dague <s...@dague.net> wrote: >>> >>> So I'm one of the first people to utter "if it isn't tested, it's >>> probably broken", however I also think we need to be realistic about >>> the fact that if you did out the permutations of dependencies and >>> config options, we'd have as many test matrix scenarios as grains of >>> sand on the planet. >> >> I think it makes sense to at test with all the most recent versions. >> Perhaps all the lowest as well, though I'm not sure how common that >> configuration would really be. And we can't do all of the various >> combinations. >> >> But how about testing on a periodic job the version >> configurations used by some of the major distros? So we know on which >> distros we're going to be broken on by default (if we don't get around >> to fixing them straight away) which will really help inform those >> trying out the latest from git. Or are the distros doing this anyway >> (either way having the info public and feeding back to our bug tracker >> would be handy). > > Honestly, I think our experience in even doing a homogenous gate means I > think we should let the distros come in with 3rd party testing on those > results. Because we don't really have the bw, in either people or > machines, to explode that matrix much in infra. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > https://urldefense.proofpoint.com/v1/url?u=http://dague.net/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=t%2BccgWNa3RGhEJzfoLbZKcoWP6fDp0ZLoIyTd0CiIdk%3D%0A&m=kRy3u472erydn9aD1jOg%2FCQqzv1p0pQeNd%2BI8WXeZLk%3D%0A&s=493bac7a717a985bdb4d64eca320969ecb2a6df00d7ee8f5d8bcaf895dd24fe8 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=t%2BccgWNa3RGhEJzfoLbZKcoWP6fDp0ZLoIyTd0CiIdk%3D%0A&m=kRy3u472erydn9aD1jOg%2FCQqzv1p0pQeNd%2BI8WXeZLk%3D%0A&s=d484eedf637b01155f20eeda79378a9d506d6a39060517e70e868dcab571f3c6
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
