Pywikibot 2.0 has been branched before the switch to 'requests' so be an interim solution for people who consider new dependencies to be a breaking change or cant install httplib2 and want 'externals'.

As a result 2.0 doesnt contain all the compat backports and compatibility, or features otherwise desired. And this task now tracks '2.1'.

So we can go with the breaking changes?!? :-O

In T72936#1341338, @Ricordisamoa wrote:

So we can go with the breaking changes?!? :-O

A change in expectations for master will need to be collectively decided...

My general and not well thought through ideas on this..

Underlying my thoughts about this: If lots of crap is getting merged into 2.0, especially without proper reviews (even for backports), then I will just wash my hands of that branch/release, for good or ill. Our small team doesnt have enough manpower to maintain a stable 2.0 which has lots of changes landing in it. I am only happy to help with 2.0 if it goes into conservative maintenance mode.

I'm guessing we'll still have lots of bot operators using master (otherwise we'll need to backport too much stuff into 2.0), so it needs to be quite stable, and mostly maintain backwards compatibility, but it can probably be more aggressive about landing development features and maybe even breaking stupid stuff.

2.0 probably wont be the compat killer, in which case 2.1 would need to add compat-compatability for 'things used in a sensible compat script'. My guess is that master will be the landing branch for any features to be backported to the 2.0 branch, which would also mean that compat-compatibility is still an objective for 'master' until we finish 2.1. (we may find that the MW API team become the compat killer, e.g. with the query-continue switch about to happen in July - I think I'm going to go on a volunteering-holiday that week, and do only real paid work for a change ;)

Where we could (and I think should) be more aggressive in breaking changes is 'old core crap' - stuff added in core , that never existed in compat , but is also no longer needed or wanted in core (e.g. httplib2, interwiki.py?, etc).

(imagine my displeasure when I had long chat over lunch at Lyon with someone who uses interwiki.py regularly on a large non-Wikimedia site (family) which doesnt intend to ever add a Wikibase - arghhhh)

In T72936#1341398, @jayvdb wrote:

2.0 probably wont be the compat killer, in which case 2.1 would need to add compat-compatability for 'things used in a sensible compat script'. My guess is that master will be the landing branch for any features to be backported to the 2.0 branch, which would also mean that compat-compatibility is still an objective for 'master' until we finish 2.1.

In https://gerrit.wikimedia.org/r/178647, @jayvdb wrote:

This can happen after we release 2.0, which will provide compat users a stable and smooth version to migrate to.

A 'feature' that was deprecated 7+ years ago...

Well 2.0 turns out to a stable 'core' for bot operators who like core but dont like using pip, or requests, or something. It wasnt my choice or decision that 2.0 would be what it has become.

So 2.1 will likely be the 'smooth' migration path for compat users. (and .getFileMd5Sum is a compat feature)

Additional blocker: T102462 must be solved or T101228 must be reverted before we can release the next candidate.

Note that pywikibot 3.0.20170521 has been release to pypi, so this tasks title is now wrong, and maybe the intention of this task is also now invalid.

The whole release and backporting thing failed completely. We switched to a strategy where we release master every once in a while when all the tests are green. I think this task can be closed as invalid.

Maybe T1315 should be edited in the same manner like this task? Or merged into this one?

Running release schedule? Was something changed for T130568 and T162560?

Finally the description should be changed too ;)