EPEL RFC: Strategy for python3 versions - epel-devel - Fedora mailing-lists

29 Apr 2014


      Hi guys,
Orion has submitted a python34 package for EPEL and I'm going to review them
soon if no one beats me to it.  In parallel with getting that approved I'd
like to ask about the general strategy we'd like to take with maintaining
python3 in EPEL.
Python3 is an evolving language.  New 3.N releases bring new features,
bugfixes, and both backwards compatibility breaking and backwards
compatibility enhancing changes (For instance, 3.3 brought the ability to
mark regular text strings with the "u" prefix to match with python2.x.  3.5
will bring back formatting methods for byte strings.)
Currently, there are a good many python libraries that work with both
python2 and python3 but few libraries and few applications that are
python3-only.
Upstream, python3 releases generally see 18 months of bugfix updates and
5 years of security fixes[1]_.
As Orion has pointed out, it would be hard for us to maintain a python3
release past upstream's EOL date as there's a lot of code in a python3
package (Not to mention the stack of packages that we'll build on top of
it.)
In addition, I am a little worried about the amount of time we may end up
having to devote to keeping multiple python3.N packages (and stacks of
packages for them) alive if we only retire old python3 releases when
upstream ceases to provide support for them (back of the envelope
calculations are that if we don't skip any python3.N releases, we'd be
attempting to maintain 4-5 python3 releases before the first of those EOL's
upstream).
I'd like to propose that we attempt to maintain 2 python3 releases at any
one time.  We'll create python3.4 now.  When python3.5 comes out in 18
months (less since python3.4 has been out for several months), we'll
package that in addition.  When python3.6 comes out (3 years), we'll package
that and retire python3.4.
Pluses:
* This gives users some time to verify that their homegrown applications
  continue to work with the newer python3 package that we produce before the
  old one goes EOL.
* This means that we're only working on 3 versions of python3 at a time (the
  two we expect users to use and the next version that we're tracking as
  upstream works on finishing it).
* This gives us a chance to update frameworks, libraries, and other stacks
  of software built on top of python3 at the same time as we create the new
  interpreter package.  So you could get python3.4 with Django-1.6.x  and
  you could get python3.5 with Django-1.8.x
Negatives:
* Users will have to reverify and port apps written against python3 to the
  new interpreter version sometime in the 3 year lifespan of the python3
  package they originally wrote it against.
* Package maintainers who are creating packages that run on python3 will
  need to submit new packages for python3.4, python3.5, etc.
* Users may have to port to both new versions of python3 and to new versions
  of some libraries they depend on (because we took the opportunity to
  update those libraries for the new python3 interpreter stack).
Precedents:
* With mediawiki, we now ship versioned packages and retire the old versions
  when upstream stops shipping updates.  The stacks of packages built on top
  of mediawiki have to be produced for each mediawiki version.
Alternatives:
* Never retire the python3 packages.  This leaves us trying to support the
  release once upstream stops support.  Since new python3 releases are in
  demand, we'd probably end up trying to maintain all of the python3
  releases that came out between when RHEL-N was released and when
  RHEL-N+1 releases (because maintainer focus usually shifts to building
  packages for RHEL-N+1 then).
* Retire the python3 packages when upstream stops support.  This defers the
  pain for users (They can use a python3.N version for about 5 years instead
  of about 3 years).  However, it means that we're maintaining 4-5 versions
  of python3 at a time instead of 2-3
What do people think?  Is this something we can do within the policies of
EPEL?  Does it make sense to go forward with this?  Is it better to go with
one of the alternatives?
.. [1]_: Previous versions of python3 have a lifespan defined in their PEP.  For
  instance, this one for python3.3:
  http://legacy.python.org/dev/peps/pep-0398/#lifespan
The lifespan for the previous versions are the same:
  * bugfix updates for python3.N approximately every 4-6 months for
    approximately 18 months.
  * After the release of python3.N+1, a final bugfix of python3.N is released.
  * After that, security updates (source only) will be released until 5 years
    after the initial release of 3.N.
3.4 doesn't have this lifespan section but that's probably an oversight (I
  can ask Larry Hastings to clarify that if need be).
-Toshio