Agree, we have had this discussion on this list before and the consensus
was to maintain compatibility and support the latest stable version
available in either the LTS of each given OS or the latest available stable
released version from the languages website if it was not directly
available as a package for those LTS versions of the OS. Our Docker setup
and test suite seems like the most logical stop to maintain this and
demonstrate recommended version and dependency install process

-Jake

On Mon, Apr 9, 2018 at 8:55 AM, James E. King, III <[email protected]> wrote:

> We have an open PR that has some incompatible changes for py2 that resolve
> utf8 issues.
>
> https://github.com/apache/thrift/pull/1274
>
> From python's own web site:
>
> https://wiki.python.org/moin/Python2orPython3
>
> Python 3.0 was released in 2008. The final 2.x version 2.7 release came out
> in mid-2010, with a statement of extended support for this end-of-life
> release. The 2.x branch will see no new major releases after that. 3.x is
> under active development and has already seen over five years of stable
> releases, including version 3.3 in 2012, 3.4 in 2014, 3.5 in 2015, and 3.6
> in 2016. This means that all recent standard library improvements, for
> example, are only available by default in Python 3.x.
>
> py3 was released 10 years ago.  Is py2 still so widely used (i.e. is more
> than half the installed base using it still) that we need to continue to
> support it in thrift?  I would like to simplify the compatibility matirx in
> thrift by dropping py2 support.  Folks who need py2 can still use thrift
> 0.11.0 or earlier to make py2 work.
>
> We have a similar problem with go, since 1.8 and earlier are not supported
> by the goland project any more, but we support back to 1.2 right now and
> want to drop 1.6/1.7 context code.
>
> In general, already-released thrift libraries can support older language
> versions, but I think the project needs to move forward.  We're starting to
> see impossible situations where fixing something for one version of a
> language breaks an older one, and so far we haven't been accepting those
> changes.  I would like to challenge that behavior.
>
> Thoughts?
>
> - Jim
>

Reply via email to