On Jan 09, 2017, at 02:28 PM, Michael Lustfield wrote: >Python uses the microversion position for this. More importantly... is this >really a point that matters? Not really. In Debian terms you might think about the first digit as an epoch, the second digit as a major version and the third digit as a minor version. There are policies in place for deprecation cycles, and Python developers do try to maintain backward compatibility where possible. Sometimes, as per policy, things that were deprecated two major releases ago get removed, but few people noticed the deprecation, so packages break. It shouldn't be surprising, but it is. (Aside: I've ported most of my own stuff to Python 3.6 and have noticed very little breakage. Much less than porting from 3.4 to 3.5, so I'm hopeful that this transition will be easier. E.g. for GNU Mailman 3, we got bitten by a re module change that had been silently --to us-- deprecated in 3.4, but it was easily fixed.) As much as Python developers would like it otherwise, upstream library and application developers are just as overworked as we all are, so they often don't proactively test against new versions of Python until after the release. This happens every time and I just don't know what you can do about it. I think Python transitions actually demonstrate good synergy between Debian and Ubuntu. Depending on where each distro is in its cycle, a Python transition can happen in one distro or the other first, but the work always feeds back to the other, and preferably back to upstream library and application developers. Because of where we are right now, I'm hoping that Ubuntu can start doing some test rebuilds against Python 3.6 because we really don't *know* the state of the Python ecosystem until that happens. Of course, we can and do also look to other Linux distros for data, fixes, and collaboration. Cheers, -Barry
Attachment:
pgpRe2QZifnWw.pgp
Description: OpenPGP digital signature