On 5/15/19 2:07 PM, Ben Nemec wrote:
On 5/15/19 1:40 PM, Jeremy Stanley wrote:
On 2019-05-15 13:08:32 -0500 (-0500), Ben Nemec wrote: [...]
The reason we did it this way is to prevent 1.6.1 from blocking all of the repos again if it doesn't fix the problem or introduces a new one. If so, it blocks the uncapping patches only and we can deal with it on our own schedule.
Normally, if it had been treated like other linters, projects should have been guarding against unanticipated upgrades by specifying something like a <1.6.0 version and then expressly advancing that cap at the start of a new cycle when they're prepared to deal with fixing whatever problems are identified.
Yeah, I guess I don't know why we weren't doing that with bandit. Maybe just that it hadn't broken us previously, in which case we might want to drop the uncap patches entirely.
We discussed this in the Oslo meeting and agreed to leave the cap in place until we choose to move to a newer version of bandit. That brings bandit into alignment with the rest of our linters. I'll go through and abandon the existing uncap patches unless someone objects.