Page MenuHomePhabricator

Important tasks to be solved (tracking)
Closed, InvalidPublic

Details

Reference
bz70936

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
InvalidNone
ResolvedNone
ResolvedNone
ResolvedDvorapa
ResolvedXZise
DeclinedNone
ResolvedXqt
Resolvedjayvdb
Resolvedmurfel
Resolvedjayvdb
Resolved Ladsgroup
OpenNone
Resolvedjayvdb
ResolvedXqt
Resolvedjayvdb
ResolvedNone
ResolvedGallaecio
ResolvedXqt
ResolvedNone
Resolvedjayvdb
OpenFeatureNone
InvalidNone
ResolvedNone
Resolvedjayvdb
ResolvedXqt
ResolvedXqt
ResolvedNone
ResolvedXZise
ResolvedUnicodesnowman
Resolvedjayvdb
ResolvedLokal_Profil
OpenNone
OpenNone
Resolved Ladsgroup
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedXqt
ResolvedXqt
Resolvedjayvdb
ResolvedXqt
ResolvedXqt
OpenNone
ResolvedNone
ResolvedXZise
DeclinedXqt
ResolvedXqt
OpenTol
Resolvedjayvdb
Resolvederanroz
OpenNone
OpenFeatureNone
ResolvedNone
Resolvedjayvdb

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
jayvdb renamed this task from Pywikibot 2.0 [tracking] to Pywikibot 2.1 [tracking].Jun 5 2015, 1:26 PM
jayvdb set Security to None.

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

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)

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.

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.

Nemo_bis renamed this task from Pywikibot 2.1 [tracking] to Pywikibot 2.1 (tracking).Aug 23 2015, 12:21 PM

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.

Xqt renamed this task from Pywikibot 2.1 (tracking) to Important tasks to be solved (tracking).May 28 2017, 11:50 AM
Xqt removed a project: Release.
Xqt updated the task description. (Show Details)

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

release 3.0 is published already

valhallasw changed the task status from Declined to Invalid.May 28 2017, 2:01 PM
valhallasw subscribed.

@Xqt prioritized the tasks, and as we are back to a rolling release schedule, this task no longer serves its original purpose.

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

Finally the description should be changed too ;)

Xqt changed the status of subtask T73738: API to use Warning system from Resolved to Declined.