Python 2 should be updated at some point

[dgelessus]

Pythonista uses 2.7.5 (released on 2013-05-15), the current latest version is 2.7.11 (released on 2015-12-05), and 2.7.12 is coming soon (planned on 2016-06-25, that's next week!). Might be good to update to 2.7.12 once that comes out.

[cclauss]

Moving target...

• We now have Python 2.7.12 in Pythonista but the current Python 2 is v2.7.13.
• We now have Python 3.5.1 in Pythonista 3 but the current Python 3 is V3.6.0.

[zrzka]

311014 does include 2.7.12 and 3.6.1. Latest available versions are 2.7.14 and 3.6.3.

Tempted to close this issue, because the Pythonista release cycle is pretty long and it will always contain outdated Python version - issue, which will never be closed.

WDYT @dgelessus?

[cclauss]

My sense is that this is an issue but it is low priority issue compared to the modules being out of date https://github.com/cclauss/pythonista-module-versions

[dgelessus]

TBH I don't mind too much if Pythonista is a couple of bugfix versions behind. There's usually a new bugfix release every 3-6 months, it's understandable that Pythonista isn't always on the absolute newest version. However at the time I made the issue, the Python 2 version was three years old and seven bugfix releases behind.

I agree with @cclauss that the included third-party libraries should be updated too. However that isn't always an easy task. Every library has a different versioning scheme, release schedule, and rules about deprecating/removing old APIs. Updating the included libraries would require checking the changelog for each one to see if there are any possibly breaking changes - especially for compiled libraries, where users can't just install an older version themselves if the new version breaks their scripts.

[zrzka]

Decided to close this one. Reasons:

• Release cycle of Pythonista is pretty long and it will always contain outdated Python version.
• OPs request to update to 2.7.12 is fixed.
• Module updates should be filled as separate issues with labels 3rd-party-module, enhancement, so every module can be discussed in one specific issue where we can help with testing, checking change logs, compatibility, ...

[cclauss]

Please don’t create a new issue for every third party module that is outa date since almost all of them are and this repo is already very chatty.

[zrzka]

I still think that my thoughts on this are unclear to people. Here's more detailed explanation ...

Python interpreter version

Let's say someone fills an issue requesting Python 3.7. Few months later, Pythonista is released, it includes 3.7 and 3.7.1 is available. Same user adds comment to the same issue that there's 3.7.1 available. And now what should be done? Issue closed, because OPs request for 3.7 was fulfilled? Or keep it open and force Ole to read all the comments to get a clue what the issue is all about? Change issue title to 3.7.1? I mean, one way is to have never ending (not closed) issue about new interpreters forcing Ole to read all these comments to get a clue which version is requested. Another way is to close it and report request for newer version. Second one is much more cleaner, less work for everyone (reading comments, ...). If this issue is opened for months, years, ... what's the purpose? Everyone knows that Ole is keeping an eye on Python versions, hired some guy, ... That's the reason why I think we should close these issues.

Modules

First thing to think about is compatibility. I simply disagree with let's update everything to the latest version. Modules can contains breaking changes. Some of them follow semantic versioning, some of them not. And even if they do, they still can contain breaking changes. It's time consuming to go through change logs, test them and make a decision to update or not to update. Can you imagine one issue, which will contain generic request to update modules? That Ole will be forced to read all comments to check what version is requested? Comments about all these versions, modules, ... in one issue? It will be a really big mess. Never ending (not closed) issue without any purpose. I don't know what Ole thinks, but I assume he doesn't want to break users scripts. It must be processed kinda carefully.

How I think it should work? Ole is keeping an eye on some modules. They'll be updated automatically. Are you using a module which has never version available? Search issue for 3rd-party-module. If the module is there, add comment. If the module is not there, file a new issue. Compatibility, ... whatever can be discussed in this issue. And if module will be updated, issue will be closed.

You're not using module X and this module is outdated? Don't file an issue just because there's new version. Some of the Pythonista users already relies on this module, maybe on the specific version and it can break their scripts. Wait till someone raises hand and says, update would be nice.

From this point of view, I think that Pythonista should use kind of semantic versioning as well. I mean, major.minor.patch. Hey, user, major wasn't changed, your scripts will still run under this version of Pythonista.

Hey, user, major was changed (and at this stage, all modules can be updated to the latest & greatest & tested), be aware that you'll have to check your scripts. There're breaking changes in some modules.

Not speaking on behalf of Ole or Pythonista, it's just my own opinion and reasoning why I did close this one and will close any generic issues like update all modules to the latest & greatest.

I think that we can help Ole by writing a script, which will list all included 3rd party modules, their versions and then we can get latest version from PyPI, dump a table to a Markdown document and include generated document in this repository for example. IIRC something like this already exists and I think that you (Chris) wrote it. Not sure, have to check.

[cclauss]

https://github.com/cclauss/pythonista-module-versions