[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python 3.6 in stretch

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

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


Attachment: pgpRe2QZifnWw.pgp
Description: OpenPGP digital signature

Reply to: