I have the same view (and the same experience fixing broken bots). It seems to me that this project has forgotten an important design principle: “If it ain’t broke, don’t fix it”!
From: firstname.lastname@example.org <email@example.com> on behalf of Maarten Dammers <firstname.lastname@example.org>
Sent: Saturday, November 13, 2021 1:55 PM
Subject: [pywikibot] Re: Deprecation policy?
I'm with Strainu on this one. Let's take an example: Someone decided
that handleArg didn't look pretty enough and renamed it in January this
year. So far so good, but 4 months later the redirect was removed .
Why was this redirect removed? Don't you realize dozens of robots use
Pywikibot as a library? For me alone this broke over 40 jobs.
I appreciate time and effort being spend on improving the framework, but
here you derailed.
On 13-11-2021 13:12, Strainu wrote:
> Hi folks,
> I'd like to bring this thread back to life since in the months passed
> *a lot* of deprecated code has been removed, some of which was quite
> "recent". I totally understand that projects move forward, and so does
> Python, I totally understand the developer's whish to use new language
> features and I don't believe we should keep deprecated code for
> decades, as it often happens in wikis. However, given that the vast
> majority of Pywikibot users are busy volunteers and that many projects
> depend on (mostly unsupervised) pywikibot code for critical
> maintenance work, I believe we need some kind of pedictibility on
> As a user, I would like to understand:
> 1. when and how can a function become deprecated
> 2. when and how can a parameter become deprecated
> 3. how long will I still be able to use a deprecated function or parameter
> 4. what Python versions will Pywikibot support.
> For 3, I propose to maintain a compatibility for *at least* 3 years.
> This roughly matches the Debian lifecycle, as the longest-maintained
> non-LTS release of major Linux distributions.
> For 4, I propose to support a Python version (e.g. 3.5) untill all of
> the following are true (that is, the longest period between them):
> - two years after official support has ended (e.g. 7 years after launch) AND
> - one year after Toolforge moved to a newer Python version. AND
> - the percentage of users of a version goes under 5%
> This should allow both Toolforge and independent users ample time to
> update their code without surprises, even when using LTS releases.
> What do you think? I would love to see feedback from both developers
> and users on these questions and possible answers. Even if you don't
> agree with these proposals, please make your own, so that we can
> hopefully agree on some rules - any deadlines would be better than
> În vin., 30 apr. 2021 la 00:33, Kunal Mehta <email@example.com> a scris:
>> Hi Damian,
>> On 4/21/21 2:32 PM, Damian Johnson wrote:
>>> What is pywikibot's policy regarding code deprecation? Can we remove
>>> it after a set duration and, if so, what is it?
>> I'm not aware of Pywikibot having such a policy, but I think it would be
>> a good idea to have one. MediaWiki has a stable interface policy
>> which defines what parts are stable to build on top of and which are
>> considered internal and then a process on how to deprecate and make
>> changes to what's supposed to be stable.
>> One of the things I worked on for MediaWiki's deprecation process is
>> developing codesearch which makes it pretty straightforward for
>> developers to see what methods/functions are practically being used and
>> see what use cases are. I think something like that would be valuable
>> for Pywikibot as well, but code for most bots/scripts is really all over
>> the place. Something like Toolhub would help with this too.
>>  https://www.mediawiki.org/wiki/Stable_interface_policy
>>  https://codesearch.wmcloud.org/search/
>>  https://meta.wikimedia.org/wiki/Toolhub
>> -- Legoktm
>> pywikibot mailing list
> pywikibot mailing list -- firstname.lastname@example.org
> To unsubscribe send an email to email@example.com
pywikibot mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com