Hi, On Wed, Jan 25, 2017 at 4:52 PM, Donald Stufft <don...@stufft.io> wrote: > > On Jan 25, 2017, at 12:27 PM, Eric Brunson <brun...@brunson.com> wrote: > > It wasn't until recently the I realized how quickly releases to setuptools > and pip are being made, starting back in mid Dec when much of our dependency > resolution started failing. There were three releases in the past two days. > Four major and 22 minor releases in the past two months. While I applaud > the speed of development and the improvement in these tools, don't you feel > that breaking changes should be advertised better before release or perhaps > we should slow down the cadence for release? > > I think an expectation that every setuptools user in the community start > their day by checking to see if there was a release in the past 24 hours is > a little unreasonable. I've spent a dozen hours since 32.0.0 resolving > breakage in my own projects and assisting other developers in my org with > their setuptools issues, all the while pushing setuptools as the best > practice to do development and distribution. Is this period of breaking > changes a short term thing that we just have to tough out for a few more > weeks? > > Thanks, > e. > > > > I don’t believe that pip is really releasing that quickly. We generally make > 1-2 “major” versions a year that include breaking changes, 2-4 “minor” > releases a year that add new features, and 6-10 patch releases that fix > bugs. To me that feels like a pretty decent pace of balancing not breaking > people and getting new changes into people’s hands and getting rid of broken > or less optimal parts of the code. > > Now, setuptools is releasing faster than pip is and whether that’s a good > thing or not I don’t know. That’s a question for Jason largely :)
It sounds like we need to get some continuous integration to bear on this problem. How about the following suggestion: before new releases, make release candidates for pip, wheel, setuptools and virtualenv, upload to pypi, announce here. Then we the dependent projects can have a continuous integration entry which tests our normal pip install with the --pre versions of these packages, to screen for trouble. I think that would catch many of the problems, and it doesn't seem like it would be much work for the package maintainers. Cheers, Matthew _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
