Change Details

Moved here from https://www.mediawiki.org/wiki/Requests_for_comment/Deprecate_pywikibot-compat Background ------------- Currently, the Pywikibot framework is split in two branches: 'core' (formerly 'rewrite') has full API support and is much more up-to-date with new MediaWiki features, while 'compat' (formerly 'trunk') is old and largely based on screen-scraping. I know of many bot-operators and developers that ported their scripts to the core branch. When I (Ricordisamoa) switched to 'core' (not much after that I started developing my bot, actually) I felt at first confused – also because of the annoying lack of documentation, for both core and compat – but then I understood that the old version was much more messy. Problem --------- I am working on several bugfixes for core, along with a couple major changes (support for Flow and editing of multiple Wikibase claims at once) but I know that no one will take care of backporting them to compat. MediaWiki and its extensions are evolving fast, and we cannot keep two different bot frameworks up-to-date. Also, the documentation does not always tell them apart, and this is raising issues with less-experienced operators. Some others are also working to make the framework compatible with Python 3 (bugzilla:58053), and again: why two versions? Proposal ---------- Now, I am proposing to declare 'compat' officially deprecated in favor of 'core' and give notice of this on mail:pywikipedia-l and mail:pywikipedia-announce. Of course, we will have to solve {T57880} before. We could even port some of the screen-scraping techniques to core, if API access is a problem for someone. But we should definitely keep them in a separate file. Timeframe ------------ * April 2014: original RFC * May 2015: moved to Phabricator * mid May 2015: Hackathon discussions on the following subjects: * ...

Moved here from https://www.mediawiki.org/wiki/Requests_for_comment/Deprecate_pywikibot-compat =Background= Currently, the Pywikibot framework is split in two branches: 'core' (formerly 'rewrite') has full API support and is much more up-to-date with new MediaWiki features, while 'compat' (formerly 'trunk') is old and largely based on screen-scraping. 'compat' currently gets no new features, and bug fixes are implemented very slowly. This means compat effectively is deprecated already, but this has not been explicitly pointed out to the community. =Problem= There are several issues with this status quo: * Documentation is partially still compat-based, confusing newcomers * Even worse, some newcomers start with compat because of that * Bug fixes are expected when compat breaks All in all, many wasted man hours that could have been used more effectively. =Goal= Defining the long-term deprecation status for compat, and communicating this to the community. = What do we mean with 'deprecation'?= * Code: * Do 'we' no longer provide new features? * No general bug fixes, but still some important ones (e.g. api access broken)? * No bug fixes at all? * Do we still accept 3rd party bug fixes? * Documentation: * Just mark documentation as deprecated? * Move it? * Remove it? * Warning for users they should migrate? == Deprecation does *not* mean: == * Actively preventing compat users from using compat = Blocking issues = Before we can deprecate compat, these issues *must* be solved: * ... = Open questions = * How do we define deprecation? (see above) * What to do with the large set of scripts that have not been migrated. = Blocking issues = There is a list of potentially useful things at {T57880}, but none of them look blocking to me. = Timeframe = * April 2014: original RFC * May 2015: moved to Phabricator * mid May 2015: Hackathon discussions on the following subjects: * ...

Moved here from https://www.mediawiki.org/wiki/Requests_for_comment/Deprecate_pywikibot-compat Background -------------=Background= Currently, the Pywikibot framework is split in two branches: 'core' (formerly 'rewrite') has full API support and is much more up-to-date with new MediaWiki features, while 'compat' (formerly 'trunk') is old and largely based on screen-scraping. 'compat' currently gets no new features, and bug fixes are implemented very slowly. This means compat effectively is deprecated already, but this has not been explicitly pointed out to the community. =Problem= Currently, the Pywikibot framework is split in two branches: 'core' (formerly 'rewrite') has full API support and is much more up-to-date with new MediaWiki features, while 'compat' (formerly 'trunk') is old and largely based on screen-scraping. I know of many bot-operators and developers that ported their scripts to the core branch. When I (Ricordisamoa) switched to 'core' (not much after that I started developing my bot, actually) I felt at first confused – also because of the annoying lack of documentation, for both core and compat – but then I understood that the old version was much more messy.There are several issues with this status quo: Problem * Documentation is partially still compat-based, confusing newcomers --------- * Even worse, some newcomers start with compat because of that I am working on several bugfixes for core, along with a couple major changes (support for Flow and editing of multiple Wikibase claims at once) but I know that no one will take care of backporting them to compat. MediaWiki and its extensions are evolving fast, and we cannot keep two different bot frameworks up-to-date. Also, the documentation does not always tell them apart, and this is raising issues with less-experienced operators.* Bug fixes are expected when compat breaks Some others are also working to make the framework compatible with Python 3 (bugzilla:58053)All in all, and again: why two versions?many wasted man hours that could have been used more effectively. Proposal=Goal= ----------Defining the long-term deprecation status for compat, and communicating this to the community. = What do we mean with 'deprecation'?= * Code: * Do 'we' no longer provide new features? Now, I am proposing to declare 'compat' officially deprecated in favor of 'core' and give notice of this on mail:pywikipedia-l and mail:pywikipedia-announce. Of course, * No general bug fixes, but still some important ones (e.g. we will have to solve {T57880} before.api access broken)? We could even port some of the screen-scraping techniques to core, if API access is a problem for someone. But we should definitely keep them in a separate file. * No bug fixes at all? * Do we still accept 3rd party bug fixes? Timeframe * Documentation: ------------ * Just mark documentation as deprecated? * Move it? * Remove it? * Warning for users they should migrate? == Deprecation does *not* mean: == * Actively preventing compat users from using compat = Blocking issues = Before we can deprecate compat, these issues *must* be solved: * ... = Open questions = * How do we define deprecation? (see above) * What to do with the large set of scripts that have not been migrated. = Blocking issues = There is a list of potentially useful things at {T57880}, but none of them look blocking to me. = Timeframe = * April 2014: original RFC * May 2015: moved to Phabricator * mid May 2015: Hackathon discussions on the following subjects: * ...