Hi folks,

regarding to your contributions and comments here some thoughts:

Currently Python 3.5.0+ is supported with stable version. With Pywikibot 7.0 Python version 3.5.0 - 3.5.2 are no longer supported due insufficient import support and other problems which could not be solved easily. [1] 

On the other hand pywikibot 7.0 comes wit PyPy support and Python 3.11. I've migrated most tests from TRAVIS to github actions and added tests for thoses versions and btw for MacOS too.

Both Python 3.5 and 3.6 have exceeded their end of life [2] and it would be appropriate to change to 3.6+ support only because this release comes with important release highlights (f-string literals, variable annotations, asyncronous generators and comprehensions, order-preserving dicts and keyword arguments, simpler customization of class creation, path-like objects, default utf-8 support with Windows. Unfortunately Toolforge does not support it.

I am mainly fine with Strainu's recommendation about dropping Python version support which was:
- two years after official support has ended
- one year after Toolforge moved to a newer Python version
- the percentage of users of a version goes under 5%

But I think this policy should also take into account that some outdated Python version may hinder further development and forcing a higher bugfix release is necessary in some cases. [1] For example Python 3.5 support ended in September 2020 but is is not appropriate to wait until September 2022 to desupport all releases. Python 3.5.2 was released in June 2016 and I think its support can be safely be dropped 5 years later if it is not used on Toolforge and their usage is below 1%.

I postponed the deployment of Pywikibot 7.0 several times. Anyway it comes with several improvements [3]. An important change is support generate_user_files and generate_family_file helper scripts with site-package [4] as well as shell and version scripts. This is a first step to support external scripts with the pwb wrapper script which is now a site package code entry point. Refer the doc for other more or less important changes.

On the other hand a lot of code cleanups were made in 7.0. Yes I think a lot of code cleanups were to fast in past which sometimes gave only 3 months of deprecation warnings. This should be changed with semantic versioning and old code should be kept for a longer time. But having a long deprecation period is not always feasible. For example removing the threadedhttp module and returning a Resonse object with http.requests() in Pywikibot 6.0 or bot option handling change in Pywikibot 5.0 came with new designs and I don't see a feasible way to support several implementations in parallel for years; this would be too time consuming for developing and debugging, too error-prone having such mixed code, difficult and expensive for testing, especially when there are only a few developers.

I don't think that the deprecation period is really important but I learned it might be important not to have code changes every month; this is the main reason to change to semantic versioning after Pywikibot 6.4. For example deprecations introduced with 7.0 will not be removed earlier than with Pywikibot 9.0 which probably comes in 2023.

Some other ideas and proposals: There is a maintenance script "update_script" originally implemented to support compat to core changes. This could be expanded to support version code changes too; helping hands are welcome. We have a stable branche preferable for production systems but testing the master branch with real data and applications is very welcome. Finally update the framework if appropriate or necessary but always refer the documentation about possible breaking changes and run your script before an update and pay attention about deprecation warnings which are always FutureWarnings and aren't suppressed by default anymore. You may use the -simulate option for those tests. If your script does not use handle_args command line parser, the -simulate option can always be used through the pwb wrapper: python pwb.py -simulate <yourscript> <scriptoptions>.

That's for now. Thank you for your kind attention. And sorry for some trouble described lately.

Best
xqt

[1] https://phabricator.wikimedia.org/T286867
[2] https://endoflife.date/python
[3] https://doc.wikimedia.org/pywikibot/master/changelog.html#improvements-and-bugfixes
[4] https://phabricator.wikimedia.org/T107629
[5] https://doc.wikimedia.org/pywikibot/master/changelog.html#deprecations