- Mentioned In
- T74118: Pywikibot 3.0 changes [tracking]
T121948: Pywikibot 2.0rc5
T67987: Functionality existing in AutoWikiBrowser but missing from core (tracking)
T1315: Release 2.0
- Mentioned Here
- T130568: Pywikibot 3.0
T162560: Update nightlies with prepackaged 3.x releases
T1315: Release 2.0
T101228: [BREAKING] Change: Switch from httplib2 to requests
T102462: [break] request library isn't stable
Here is a good list of release candidate blockers (things that need to be fixed in order for testers to not yell at us for wasting their time):
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'.
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)
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)
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.