<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 3, 2016, 13:43 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 July 2016 at 21:22, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> Topic 2<br>
> =======<br>
> Independent releases of the stdlib could be done, although if we break the<br>
> stdlib up into individual repos then it shifts the conversation as<br>
> individual modules could simply do their own releases independent of the big<br>
> stdlib release. Personally I don't see a point of doing a stdlib release<br>
> separate from CPython, but I could see doing a more frequent release of<br>
> CPython where the only thing that changed is the stdlib itself (but I don't<br>
> know if that would even alleviate the RM workload).<br>
<br>
The one major downside of independent stdlib releases is that it<br>
significantly increases the number of permutations of things 3rd<br>
parties have to support. It can be hard enough to get a user to report<br>
the version of Python they are having an issue with - to get them to<br>
report both python and stdlib version would be even trickier. And<br>
testing against all the combinations, and deciding which combinations<br>
are supported, becomes a much bigger problem.<br>
<br>
Furthermore, pip/setuptools are just getting to the point of allowing<br>
for dependencies conditional on Python version. If independent stdlib<br>
releases were introduced, we'd need to implement dependencies based on<br>
stdlib version as well - consider depending on a backport of a new<br>
module if the user has an older stdlib version that doesn't include<br>
it.<br>
<br>
Changing the principle that the CPython version is a well-defined<br>
label for a specific language level and stdlib, is a major change with<br>
very wide implications, and I don't see sufficient benefits to justify<br>
it. On the other hand, simply decoupling the internal development<br>
cycles for the language and the stdlib (or independent stdlib<br>
modules), without adding extra "release" cycles, is not that big a<br>
deal - in many ways, we do that already with projects like asyncio.<br></blockquote></div><div><br></div><div><br></div><div>This last bit is what I would advocate if we broke the stdlib out unless an emergency patch release is warranted for a specific module (e.g. like asyncio that started this discussion). Obviously backporting is its own thing.</div><div><br></div><div>-Brett</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Paul<br>
</blockquote></div>