Hello Claudiu,

> The 2.0 vs 2.0.1 problem you're experiencing with astroid was a
> problem with the 2.0 release. Due to a mistake in the release process,
> the wheel for 2.0 was in fact the last dev release of astroid. The .tar.gz
> sdist though was containing the actual 2.0 code. Not sure how
> the dev release got to be marked as 2.0 but only for the wheel file,
> but we added some additional documentation in the release process
> to ensure this doesn't happen again (although ideally we'd move
> the release to be an automatic process rather than manual as it is now)
>
> For the other issues, I suggest opening separate issues on the bug tracker
> since otherwise they can get lost here.

First of all, shit happens, and not a huge problem of course. I have
done similar. Automation is fine, but not necessary less error prone.
My static web site deployment
e.g. managed to revert to 2 years old site due to a wrongly set RTC
clock, turning all of 2 years of posts into drafts. But it it is less
work, and you got a machine to
blame. ;-)

I was mainly wondering if Astroid had an independent release process.
And I was wondering if there shouldn't have been a 2.0.1 release then
for PyLint too.

What's bound to be happening is that lots of people have "pylint"
latest installed, but not the real thing. And nothing can make them
notice.

A bump of version on PyPI would be nice, not sure if you want to go
2.0.1 there too, might be used in your roadmap thinking already, or of
2.0.0a is even allowed anymore these days.

I was of course going to report the issues to the bug tracker and just
did. Unfortunately it also indicates that it's not a minor thing, that
is changed, like a forgotten version bump,
clearly more is in there missing for people who installed it during
the time the wheel was not updated.

Yours,
Kay
_______________________________________________
code-quality mailing list
code-quality@python.org
https://mail.python.org/mailman/listinfo/code-quality

Reply via email to