Closed skshetry closed 3 years ago
I think it makes sense, beside, anticipating the effect of new astroids in old pylint is always a difficult exercise. We might have impacted the performance of pylint 2.8.2 because of #4524 and cannot expect everyone to downgrade to 2.5.6 manually if that really become a problem. What do you think @cdce8p ?
I agree, the situation isn't ideal. Usually it's not that big of a deal as we also release pylint
shortly after, but as you mentioned we have to deal with #4524 first. The only downside to limiting it that releasing becomes a bit more time consuming, since it needs to be >=
during the development period.
@Pierre-Sassoulas Do you consider releasing 2.8.3
just with astroid==2.5.7
?
Long term we might want to consider vendoring astroid
. That way we could update the astroid version pylint uses more frequently without the need for a new release. It would also negate the need for some pylint
MRs to wait until the next release before we can merge them.
With the released Astroid 2.5.7 even Pylint's selftests fail...
Some mechanism of synced releases is required, IMO. Otherwise, CI is broken again :(
With the released Astroid 2.5.7 even Pylint's selftests fail...
Two tests are not passing but only because a false negative is now detected. See #4523
I released pylint 2.8.3 with astroid pinned to 2.5.6 and upgraded the release documentation so astroid is pinned for the next release in #4533.
Thank you!
Hi there. Would it be possible to pin the astroid version? It looks like in
astroid==2.5.7
, the inference was improved and started to notify errors that were false negatives before (which is a good thing).But this makes CI fail in a surprising way. If the new release came with
pylint
, it'd have been easier to fix the errors. 🙂