Supporting both versions temporarily for one release might be helpful for a seamless upgrade path.However, of that is too much effort going directly to Python 3 sounds okay to me as well. There are a few complications with Thrift though. I have left some details on the github issue. Thanks for bringing this up!
On Sat, 2019-09-14 at 08:41 -0400, r...@chartbeat.com wrote: > We at Chartbeat are fine with the move to python 3. > > On Sep 13, 2019, at 9:40 PM, Renan DelValle <re...@apache.org> wrote: > > Folks, > > Please chime in as we need feedback from the community to figure out a > > pathforward. > > If there is no feedback received by the end of next week the plan will beto > > make 0.22.X the last version of Aurora with guaranteed support forPython2. > > Any versions released after 0.22.X will only be guaranteed to workwith > > Python3. > > -Renan > > > On Mon, Sep 9, 2019 at 2:34 PM Renan DelValle <re...@apache.org> wrote: > > > All, > > > Python 2 is on it's way out and will no longer be receiving > > > securityupdates after Jan 1st, 2020. [1] Aurora currently has a few > > > componentswhich are currently only compatible with Python 2 including > > > thermos.Running Aurora components that are only compatible with Python 2 > > > may becomean increasing security liability from the set sunsetting date. > > > I've opened up an issue on our Github to track/discuss this > > > issue:https://github.com/apache/aurora/issues/68 > > > > > > Justin Venus has been kind enough to offer his support and expertise > > > inthis field to help shepherd this really important task. > > > Right now we're looking for guidance from the community as to > > > thedirection we want to go in: > > > Do we want to drop support for Python 2 and asks users to migrate > > > toPython 3 ASAP? > > > or > > > Do we want to move towards deprecating support for Python 2 slowly > > > overthe next year with an EOL support of (around) the end of 2020 > > > whilemaintaining both Python2 and Python3 support until then? > > > Ideally, we'd go for the second approach but the truth is we're lacking > > > indevpower. If we go the second route there is no guarantee that we would > > > getthere in time to avoid putting systems at risk. > > > I'd love to hear everyone's take on this. > > > -Renan > > > [1] https://www.python.org/doc/sunset-python-2/ > > >
