Page MenuHomePhabricator

RFC removing old code / code cleanup
Open, LowestPublic

Description

Some core methods were marked as deprecated a long time ago. For example setAction() was deprecated about five or six years ago (and is still used in checkimages). Anyway do we have any suggestion for removing old or deprecated code parts? Or should it always be kept?

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Xqt raised the priority of this task from to Needs Triage.Jul 17 2015, 5:48 AM
Xqt added a project: Pywikibot.
Xqt added a subscriber: Xqt.
Restricted Application added subscribers: pywikibot-bugs-list, Aklapper. · View Herald TranscriptJul 17 2015, 5:48 AM

1 year of deprecation seems enough to me.
When releases are established, master will be able to advance even faster.

Or should it always be kept?

That's what compat ended up doing, I think?

XZise added a comment.Jul 17 2015, 9:48 AM

I think that depends on the version number it was introduced and how we want to handle version numbers. For example we could say that the first number changes if it's a breaking change, the second if something new was introduced and the third for fixes.

So if we deprecate something in version 2, all versions within verson 2 should still support it and we can remove it with version 3. Now the exception would be compat code if we consider that version 1, because version 2 intentionally supports version 1 to make conversion easier. Alternatively we can apply that to anything: Everything that was deprecated in version X is also available in version X+1 but may not be available in version X+2.

Now depending on how we are going to release it, we might say that the API between two releases may change. So basically that we can add something and break it as long as it hasn't been releases as a new version. This is basically what we already do and which is also noted (hopefully everywhere). And it doesn't really answer your question.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptFeb 10 2016, 3:08 PM
Dalba added a subscriber: Dalba.Aug 30 2016, 1:21 PM
Magul triaged this task as Unbreak Now! priority.Nov 16 2016, 4:17 PM
Magul added subscribers: hashar, Legoktm, Magul.

I'm upraising priority here, because I believe that's one of problems that we need to solve before moving forward.

I agree with @Ricordisamoa that 1 year after deprecation should be enough. I also think, that we should count this period from the first pypi (and in future conda-based) release that contains deprecation (see: #1, #2).

Moreover I believe we should abandon this overambitious plan to release first non-RC version after providing support for all compat features. I would even suggest to abandon feature-based release cycle and make it time-based. We could stick here to Mediawiki/Core release cycle (see: #3) and using SemVer (see: #4) increase major version number every 6 months (like Mediawiki does with second version number). It will give us opportunity to remove part of deprecated objects every 6 months.

@Xqt this issue is more than year old, could we establish deadline for it and don't discuss it indefinitely? I would propose here 2 weeks (that will give us possibility to release just around Mediawiki 1.28) but if You think that we need more time, just propose any deadline, please.

@Xqt, @hashar, @jayvdb, @Legoktm, @valhallasw, @XZise and others, what do You think about it?

Restricted Application added subscribers: Jay8g, Luke081515, TerraCodes. · View Herald TranscriptNov 16 2016, 4:17 PM
Magul assigned this task to Xqt.Nov 16 2016, 5:29 PM

Hi @Magul, welcome to Phabricator and our little project. We generally use "Unbreak Now!" for when something is seriously broken, this looks more like an old bug that nobody bothered to pay attention to. I don't think trying to make up some deadline is going to work here.

I would look at a case by case basis. A lot of people (including me) use Pywikibot as a library. Having a stable interface is important to not waste time on having to update old scripts. Removing deprecated functions will break bots, what is the gain?

Xqt lowered the priority of this task from Unbreak Now! to Lowest.Nov 16 2016, 11:44 PM
Magul added a comment.Nov 17 2016, 1:37 PM

Hi @Multichill, first of all thank You for such warm greeting. As I wrote already here I believe that is one of the most important questions that we need to answer here.

I made really simple test and right now we have around 1400 instances of "deprec" in source code. I believe we can say, the problem with with deprecation has the same order of magnitude. Every time we try to improve something here and encounter deprecated code we have to maintain it also. I just believe, that if we will have more and more deprecations, maintaining burden will just grow really fast. So from my POV answer to this particular question is one of most significant in the future of this project. I have revealed my opinion, but if community will decide to just keep deprecated code indefinetly I will know how to handle such code (basically not removing it) and if burden will be to much for me I will stop contributing. But I still think that it's important do decide whatsoever.

I Your case if You don't want to maintain Your code, You can pin to particular version/pypi release of library, and if You want to use new features You can just use virtualenvs to execute particular code with particular library's version. I believe You're aware of this possibilities. It will require a little more work from Your side as library user, but it will add significant change in development velocity for library maintainers (and as You know there are over 700 issues in backlog, where the oldest one live in it for more than 2 years).

@Xqt 1,5 years ago You actually create this issue and asked this question. I saw that You had lowered priority here to Lowest. That's just means that it will be handled after fixing almost all issues that live right now in backlog and it
effectively means that the answer is "We keep all deprecated code indefinetly". So maybe we should not defer resolution of this issue somehere in backlog and just close it with that answer? What do You think about it?

Xqt added a comment.Nov 24 2016, 9:56 AM

I agree with @Multichill and think deprecation warnings does not care and keeps code backward compatible. With deprecation of compat (T99365) this helps migrating to the new framework. Normally older code does not prevent further improvements. I do not see that this is a burden for further development (could you give some examples?) but it helps than it hinders. Maybe we should have a timestamp with the deprecation decorator. I propose the following rules:

What should be deprecated?

  • Any changes of method parameters should decorated with deprecated_args.
  • Any changes of method names should decorated with deprecated.
  • Any changes of instance variable names should be deprecated by deprecated and propery decorators.
  • Any changes of class properties should be deprecated by deprecated and classproperty decorators.
  • Any changes of function names should use redirect_func.
  • Any changes of command line options should be noticed with issue_deprecation_warning and the warning_class should be ArgumentDeprecationWarning.

These deprecation methods should be used for the library part only except changes of command line options. Deprecated code should keep its old behaviour.

No deprecations are necessary for the following parts:

  • Hidden variables, methods or functions (with preleading _ or __)
  • Any script parts except the are reused by other scripts; on the other hand this should not be done, see T60942.
  • Already broken code. Do not try to reinvent the wheel.

Removing of deprecated code

  • Deprecated code may be removed when it is broken (mostly by upstream changes) and not easy to fix.

Finally Pywikibot code should be cleaned and not use deprecated code.

I Your case if You don't want to maintain Your code, You can pin to particular version/pypi release of library, and if You want to use new features You can just use virtualenvs to execute particular code with particular library's version. I believe You're aware of this possibilities. It will require a little more work from Your side as library user, but it will add significant change in development velocity for library maintainers (and as You know there are over 700 issues in backlog, where the oldest one live in it for more than 2 years).

While we have only infrequent releases of the library using the pypi version is in my opinion not really a realistic solution. 2.0 is currently 1990 commits behind master and I know of at least some of them which fix breaking upstream changes, but the lag means it is getting painful to try to port them.

While we don't have some type of frequent versioned releases I would say it is difficult to get rid of the deprecated code. Now if we get (semantic) versioned releases rolling then it should be possible to set some general rules for on which version changes it is ok to drop deprecated code (or after a certain number of changes of that type).

Xqt added a subscriber: Ladsgroup.Nov 28 2016, 5:03 PM
Magul added a comment.Dec 11 2016, 5:16 PM

@Lokal_Profil Maybe it wasn't clear in my previous comments - I'm advocating for frequent releases (like in constant interval of one month). It will provide current features in commonly used format. I'm also agruing for abandoning planed release for version 2.0 (planned to be fully compatible with compat) and go with whatever is in master right now.

Of course, we just could start releasing separatly branch 2.0 and experiment with frequent releasing master branch (and see what will work for our users). We could do it as pywikibot on pypi or even release under other name. What do You think about it?

BTW there was new ticket created for releasing new code (T152907).

@Lokal_Profil Maybe it wasn't clear in my previous comments - I'm advocating for frequent releases (like in constant interval of one month). It will provide current features in commonly used format. I'm also agruing for abandoning planed release for version 2.0 (planned to be fully compatible with compat) and go with whatever is in master right now.
Of course, we just could start releasing separatly branch 2.0 and experiment with frequent releasing master branch (and see what will work for our users). We could do it as pywikibot on pypi or even release under other name. What do You think about it?
BTW there was new ticket created for releasing new code (T152907).

I agree with changing the current release plan to something more frequent and then getting rid of deprecated code with every major version change or possibly keep it for at most one major version after deprecation (so 6 months or 1 year) . I'm personally happy with either and the first solution means we don't need to keep track of when a deprecation was introduced (since any X.1.0 should be free of such), the second mean we should introduce a version label in the decorator. (similar to the comment by @Xqt in T106121#2820403).

For library users (like @Multichill and myself) it should be possible to pin a pywikibot version and only update when you want to use newer features or when MediaWiki has introduced some breaking change.

i would however leave the deprecated code until after we've released a new major version so that there is something equivalent to todays master which (library) users can pin. (2.0 is too out of date to count).

For a concrete suggestion I would start with @Xqt rules in T106121#2820403 but with Removing of deprecated code changed to saying this may only be done on major version change or may only be done on a major version change 2 larger than the major version where the deprecation was introduced.

Do we want to handle a change of release model/plan in this RFC or should that be a separate one with this one on hold until that is resolved?

Do we want to handle a change of release model/plan in this RFC or should that be a separate one with this one on hold until that is resolved?

I don't agree. The whole thing with releases is just a giant time sink. We just killed off compat to not have to worry about multiple versions any more. I'd rather have people spend time on improving Pywikibot and fixing bugs, than waste time on some release nobody uses anyway. No, I'm not going to pin on some old version. Pywikibot you run on master. If you run into an issue, you update it to the latest version. If you run into the same issue again, you file a bug and get it fixed. If people are not able to do a simple git clone/git pull, they shouldn't be running Pywikibot at all (or just http://paws.wmflabs.org/).

We tried releases, we failed, let's abandon it.

(I was subscribed so I make a note) Release engineering for pywikibot needs some work. We have three options here:

  • Going after semver (See http://semver.org/). So only major version change when there is a breaking change and minor change for minor ones. It's PEP440 compatible.
  • Going after year.month system. So pywikibot at end of January will be released as "pywikibot 2017.1". It's closer to WMF release engineering system and PEP440 compatible.
  • We can use WMF release engineering system. So at end of each of week a new release comes out (except weeks without deploy such as this week) and with the exact same number of mediawiki (see this for example) The biggest upside of this method is to being synced with mediawiki, so for example if a third party is running mediawiki core 1.29-wmf.1 he/she knows exactly what version of pywikibot to choose. And if mediawiki introduces a breaking change (which it does all the time) we can be synced too easily.
Magul added a comment.Dec 21 2016, 1:59 PM

I don't agree. The whole thing with releases is just a giant time sink. We just killed off compat to not have to worry about multiple versions any more. I'd rather have people spend time on improving Pywikibot and fixing bugs, than waste time on some release nobody uses anyway. No, I'm not going to pin on some old version. Pywikibot you run on master. If you run into an issue, you update it to the latest version. If you run into the same issue again, you file a bug and get it fixed. If people are not able to do a simple git clone/git pull, they shouldn't be running Pywikibot at all (or just http://paws.wmflabs.org/).
We tried releases, we failed, let's abandon it.

Maybe it's my personal bias here, but I started contributing here, because I was trying to use PWB by myself, and obvious choise for me to install it was via pip and requests.txt in my project. I believe it's the most common way, how Python community is installing packages right now. That's the main reason that I'm advocating for releasing it in PyPI. Regarding Your argument about "time sink" I'm not trying to persuade anybody here to support old versions already released by PyPI. I would just release newer version in frequent cycle and suggest anybody to upgrade installed version to newer one. As You can see also e.g. in T152907 I'm not the only person, that would use PyPI package. From Your perspective (cloning/fetching/pulling from git) there is no problem, that there is release in PyPI and I could find one hour a month to release current tip of master branch.

(I was subscribed so I make a note) Release engineering for pywikibot needs some work. We have three options here:

  • Going after semver (See http://semver.org/). So only major version change when there is a breaking change and minor change for minor ones. It's PEP440 compatible.
  • Going after year.month system. So pywikibot at end of January will be released as "pywikibot 2017.1". It's closer to WMF release engineering system and PEP440 compatible.
  • We can use WMF release engineering system. So at end of each of week a new release comes out (except weeks without deploy such as this week) and with the exact same number of mediawiki (see this for example) The biggest upside of this method is to being synced with mediawiki, so for example if a third party is running mediawiki core 1.29-wmf.1 he/she knows exactly what version of pywikibot to choose. And if mediawiki introduces a breaking change (which it does all the time) we can be synced too easily.

I would suggest here second option. It's clear and simple and first and third one require a little bit more work to be done.

BTW @Ladsgroup, I we have Your attention, could You add me (and maybe others) to owners group of Pywikibot on PyPI test index (https://testpypi.python.org/pypi/pywikibot/2.0rc1.post2). My login there is magul.

I added you as owner. I don't know if others have account in the test pypi. Tell me if you know anyone.

Great, thank You!

Lokal_Profil added a comment.EditedJan 9 2017, 3:28 AM

I agree with @Magul that the time sink aspects should not be very pronounced with the proposed scheme of releases since we will not be trying to maintain multiple releases.

Pip install is by far the most common way of consuming python libraries. Requiring that someone clones master and prays that they are not getting one of the semi frequent broken states (which are OK for development work) is unnecessarily cruel. In addition to that we have people wanting to release tools which incorporate pywikibot etc.

The three major things I'very identified are:

  • Someone (or better a group of someones) need to take responsibility for ensuring releasing. Ideally someone with some familiarity with pupils.
  • A stable point (at least the tests we run at github should all pass?) needs to be identified for each release.
  • Alternativt change log needs to be maintained (but I guess that wouldn't be a bad thing even if we decide not to do releases).

And as a one off we should define when/why/how we release somewhere on mediawiki.org so that new people (and us) can find it in a year.

Change 399755 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [IMPR] Introduce a timestamp in deprecated decorator

https://gerrit.wikimedia.org/r/399755

Change 399755 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [IMPR] Introduce a timestamp in deprecated decorator
https://gerrit.wikimedia.org/r/399755

If we are going to have a solely date-based version scheme, then this patch looks fine. But if semantic versioning is preferred, then I'd suggest using the version number instead of timestamp.

The current versioning system (3.0.20171212) does not look like either of them. I don't know why we have that 0 between the major version and patch version. For example in 3.0.20170713 We have added thanks log support (new functionality) which normally should bump the minor version, but we have not done so.

I'd suggest using the version number instead of timestamp.

The problem with that is that versioning is today done separately from doing a deprecating commit and to the one doing the commit the current version isn't necessarily clear.

The current versioning system (3.0.20171212) does not look like either of them. I don't know why we have that 0 between the major version and patch version. For example in 3.0.20170713 We have added thanks log support (new functionality) which normally should bump the minor version, but we have not done so.

I believe the current scheme is date versioning only but with a 3.0 prefix to distinguish it from the 2.0 efforts. We could possibly change to 3.DATE to clarify that but I'm not sure this it's needed.

This reminds me off

And as a one off we should define when/why/how we release somewhere on mediawiki.org so that new people (and us) can find it in a year.

@valhallasw Did you get an opportunity to do that?

Dalba added a comment.EditedDec 23 2017, 12:33 PM

The problem with that is that versioning is today done separately from doing a deprecating commit and to the one doing the commit the current version isn't necessarily clear.

I suppose we could use after=<latest_version> as the deprecation parameter. However, the idea was mainly for semantic versioning. For date versioning, it might not matter.

I believe the current scheme is date versioning only but with a 3.0 prefix to distinguish it from the 2.0 efforts. We could possibly change to 3.DATE to clarify that but I'm not sure this it's needed.

I guess the main question that remains is how we are going to handle backward incompatible changes in this versioning scheme.
If we are going to bump the main version for any backward incompatible change, then maybe having since=<major_version> would be enough. On the other hand, if deprecated code removal is going to be date-based only, e.g. after 1 year of deprecation as some have suggested, then a timestamp looks more appropriate.

Lokal_Profil added a comment.EditedJan 5 2018, 11:41 AM

... if deprecated code removal is going to be date-based only, e.g. after 1 year of deprecation as some have suggested, then a timestamp looks more appropriate.

Since regular releases was a problem in the past I would probably go with this to avoid re-adding some of those stumbling blocks.

Xqt added a comment.Jan 8 2018, 6:00 PM

The problem with that is that versioning is today done separately from doing a deprecating commit and to the one doing the commit the current version isn't necessarily clear.

I suppose we could use after=<latest_version> as the deprecation parameter. However, the idea was mainly for semantic versioning. For date versioning, it might not matter.

latest_version is completly unclear or in other words it is undefined. A lot of deprecation warnings are done when creating the rewrite branch from previous compat branch. We could say that compat is the 1.0 branch [1] whereas 2.0 was a separate branch based on rewrite development where some patches where ported to from time to time. After we dropped that 2.0 branch we started the 3.0 counting [2].

Finding out the deprecation history, the timestamp is the only usefull value we could extract from repository.

I believe the current scheme is date versioning only but with a 3.0 prefix to distinguish it from the 2.0 efforts. We could possibly change to 3.DATE to clarify that but I'm not sure this it's needed.

I think we should indicate the major 3 release Independent of the timestamp versioning.

I guess the main question that remains is how we are going to handle backward incompatible changes in this versioning scheme.
If we are going to bump the main version for any backward incompatible change, then maybe having since=<major_version> would be enough. On the other hand, if deprecated code removal is going to be date-based only, e.g. after 1 year of deprecation as some have suggested, then a timestamp looks more appropriate.

I propose to increase the minor release for backward incompatibility e.g. remove older depecated parts. They get a tag which is the version number [3] and could easily restored from repository (but without any backports).

But I have no preferences about the mayor release number; maybe this could indicate a new python code base or revoking some (like py 2.6 for example)

[1] https://pypi.org/project/PyWikipediaBot/#history
[2] https://pypi.org/project/pywikibot/#history
[3] https://gerrit.wikimedia.org/r/#/admin/projects/pywikibot/core,tags

Dalba added a comment.Feb 12 2018, 5:56 AM

I propose to increase the minor release for backward incompatibility e.g. remove older depecated parts.

Increasing minor version for backward incompatibility? Is there any package that does that? I think it'll confuse users.

I personally prefer a full semver system, no dates. I believe it has a well understood meaning. However, a decision needs to be made and I don't mind other systems, as long as we are clear about how the version should be changed.

Xqt added a comment.Feb 12 2018, 9:26 AM

Increasing minor version for backward incompatibility? Is there any package that does that? I think it'll confuse users.

pywikibot was preparing to do it with 2.1

I personally prefer a full semver system, no dates. I believe it has a well understood meaning. However, a decision needs to be made and I don't mind other systems, as long as we are clear about how the version should be changed.

I am fine with semver too.

Change 409823 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [PEP440] Enable semver versioning for pywikibot

https://gerrit.wikimedia.org/r/409823

Well, per semver backwards incompatibility should be noted as 4.0.0 (major,minor,patch). But I personally more like 3.1.20180212 (major.incompatibility.stamp).

Dalba added a comment.Feb 13 2018, 9:52 AM

But I personally more like 3.1.20180212 (major.incompatibility.stamp).

Under semver any incompatibility in API is considered a major change. In a major.incompatibility.stamp scheme, what kind of change will be associated with major version change? Do you know any prominent python package with this scheme?

Xqt added a comment.Feb 13 2018, 12:28 PM

I agree with Dalba. I've no idea for what the major release stands except 1.0 means trunk, 2.0 means the interim rewrite stable branch and 3 the current master which never will change in future except we have a complete code redesign.

I think semver release counting is wellknown what it means and is PEP440 compatible. And finally we can prepare the next release before published at pypi for example. Currently we mark the release after publishing which is also wrong because a new version is started then.

OK. I'm not against semver, I used it a lot in some of my older projects so I can see some serious questions we should solve before presenting this change: How this change will affect the developers? Will we require to increment PATCH number for every bugfix made and MINOR for every improvement? Or this change is just for PyPi and HISTORY.rst purposes and no developer needs to struggle with that?

PS: If we will follow semver, pywikibot could rapidly increment to 5.0.0 in several months if Py3.3 and Py2.6 abandoned separately. How would the Pywikibot users react about this massive jump? Or should dropping of old Python release support be excluded of backward incompatible changes in other way semver allows (build metadata)?

Dalba added a comment.EditedFeb 13 2018, 6:35 PM

Will we require to increment PATCH number for every bugfix made and MINOR for every improvement?

Based on our current release cycle, I presume that we can keep developing on the dev (pre-release) version. The person who is going to update the changelog and do the release, should look at the changes since the last release and bump the version accordingly.

PS: If we will follow semver, pywikibot could rapidly increment to 5.0.0 in several months if Py3.3 and Py2.6 abandoned separately.

I was hoping for it to be done in a single release, but if not...

How would the Pywikibot users react about this massive jump?

I don't know how they would react, but the same reaction that would be appropriate for an incompatibility-bump in a major.incompatibility.stamp scheme would be appropriate here, too. (Under both circumstances they should check the changelog and see if the breaking change affects them or not, and if it does, they should either update their code, or keep using the older pywikibot version.)

Or should dropping of old Python release support be excluded of backward incompatible changes in other way semver allows (build metadata)?

That question holds for current scheme, too. Should we bump the incompatibility or should we use build metadata? (The point being that even if switch over to semver, things won't change in that front.) Such a change would perhaps require a separate RfC/announcement, updating the documentation, and AFAIK using semver build metadata is not permitted under PEP 440.

Lokal_Profil added a comment.EditedFeb 13 2018, 8:10 PM

The person who is going to update the changelog and do the release, should look at the changes since the last release and bump the version accordingly.

Do we have anyone/anyones willing to take that on? If I understand the pywikibot history correctly that has been the major hurdle for releasing in the past and was the reason for the stamp solution to get releases going again.

Xqt added a comment.Feb 14 2018, 5:58 AM

Do we have anyone/anyones willing to take that on?

I did it several times in past and it is very easy to do it with master branch in opposite to the previous so called stable release 2.0.

If I understand the pywikibot history correctly that has been the major hurdle for releasing in the past and was the reason for the stamp solution to get releases going again.

As I remember it was introduced when we closed the 2.0 stable branch after a long time of um maintenance to have the master branch as the new stable release at pypi.

Personally I uploaded a new release after approximately one month when tests where successful and I tagged the last related commit with the version number created by setup.py. Also I updated the HISTORY file (not the ChangeLog which is really hard to work and I gave up) With those tags developers or bot operators are always able to went back to this release which might be important for breaking changes.

It is a problem of stamp based versioning that the new release is known after uploading it which also looks wrong because after tagging a release a new version is created. With semver this could be changed and the new release is known before uploading it including any doc strings.

Dalba added a comment.Mar 13 2018, 3:06 AM

The person who is going to update the changelog and do the release, should look at the changes since the last release and bump the version accordingly.

Do we have anyone/anyones willing to take that on? If I understand the pywikibot history correctly that has been the major hurdle for releasing in the past and was the reason for the stamp solution to get releases going again.

That's a good point. I also would like to add that we might not always agree on what is and what is not a breaking change and how often we should bump the version (another source of arguing). For example I consider changing requests requirement a breaking change...

It'll be definitely easier for us (developers) to continue to use a date based versioning, but the burden will be moved to users who will have to check the changes for each new release.

It is a problem of stamp based versioning that the new release is known after uploading it which also looks wrong because after tagging a release a new version is created. With semver this could be changed and the new release is known before uploading it including any doc strings.

Actually I think we can use a hard-coded timestamp as version. It should not matter if the version differs a few days from the exact release date. Perhaps that could be resolved by changing the way are setup.py works.

Restricted Application added a subscriber: Zoranzoki21. · View Herald TranscriptMar 13 2018, 3:06 AM
Xqt added a comment.Mar 17 2018, 4:11 PM

That's a good point. I also would like to add that we might not always agree on what is and what is not a breaking change and how often we should bump the version (another source of arguing). For example I consider changing requests requirement a breaking change...

This was not a breaking change by the bot framework but from EventStreams web service itself. pwb may run with older versions of requests but newer is needed for the sseclient working with the newly EventStreams. Anyway it doesn't care currently.

Creating a new release monthly after tests pass would be a good period I guess. On the other hand bugfixes for highly used framework parts e.g. regressions could be a good reason to do it earlier (https://gerrit.wikimedia.org/r/#/c/420170/ for example would be a candidate for it).

Actually I think we can use a hard-coded timestamp as version. It should not matter if the version differs a few days from the exact release date. Perhaps that could be resolved by changing the way are setup.py works.

I made a proposal for it and still prefer new versioning .

In https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/399755/ there can also be found multiple code blocks deprecated for even 4 or 5 years. I think that these deprecated for more than 2 years should be removed as such a long time with deprecation warning seems enough to me.

PS: Probably the versioning issue should have its own task as it sidelined the main task issue described in the task description

Dalba added a comment.Jul 17 2018, 9:58 AM
  • Any script parts except the are reused by other scripts; on the other hand this should not be done, see T60942.

Does everyone agree on this one? I plan to fix all pep8-naming errors within scripts, which will require renaming some methods, so not requiring deprecation would make things much easier.

Maybe we should move scripts directory to _scripts to make this more explicit?

Maybe we should move scripts directory to _scripts to make this more explicit?

I don't support this idea, _scripts could possibly break too many things.

Personally I would continue to deprecate parts of scripts as before.

Xqt added a comment.EditedJul 17 2018, 10:56 AM

Personally I would continue to deprecate parts of scripts as before.

We also omitted deprecating of script parts in past. Scripts are ready to use and I mean it is in the scope of bot operators if they change the script and have to rebase them. The are invited to update the current scripts if theiy want. If deprecation is needed this prevents standardizing and improvements like I've suggested on several scripts due to T196851 and it is mostly impossible to keep both the old and the new implementation.

Xqt added a comment.Jul 17 2018, 11:01 AM

Maybe we should move scripts directory to _scripts to make this more explicit?

The archive folde would be a place for older scripts if necessary. And we also have the monthly updated repository tags to easily went back to an older implementation.

Personally I would continue to deprecate parts of scripts as before.

We also omitted deprecating of script parts in past. Scripts are ready to use and I mean it is in the scope of bot operators if they change the script and have to rebase them. The are invited to update the current scripts if theiy want. If deprecation is needed this prevents standardizing and improvements like I've suggested on several scripts due to T196851 and it is mostly impossible to keep both the old and the new implementation.

I'm confused, there already are some deprecations in 7 scripts. So we just need to start deprecating in scripts? I would support to finish https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/399755/ ASAP for this.

Magul removed a subscriber: Magul.Jul 17 2018, 11:16 AM
Xqt added a comment.Jul 17 2018, 12:04 PM

I'm confused, there already are some deprecations in 7 scripts. So we just need to start deprecating in scripts? I would support to finish https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/399755/ ASAP for this.

Personally I never was a friend of deprecation script parts but I would be fine with it as long as we can implement any workflow to drop them (in short time) to enable script improvements.

For example of this imagetransfer patch you may deprecate the two renamed methods but you cannot do anything for the run method. The name has been kept but the behaviour is different.

Another sample of clean_sandbox improvements: There is nothing we can deprecate but might be a lot of breaking changes starting with SandboxBot.site Attribute or the self.translated_content which both becomes invalid.

Or have a look at makecat which is completely rewritten.

What about SemVer version for framework and for each script its own SemVer version?

Change 399755 merged by jenkins-bot:
[pywikibot/core@master] [IMPR] Introduce a timestamp in deprecated decorator

https://gerrit.wikimedia.org/r/399755

Okay, now we can remove deprecations older than 2 ( ? 3? ) years!

Change 449025 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [cleanup] Remove unsupported removeImage and placeImage Page methods

https://gerrit.wikimedia.org/r/449025

Change 449026 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [cleanup] Remove getParsedString Site method

https://gerrit.wikimedia.org/r/449026

Xqt added a comment.Jul 29 2018, 2:36 PM

Okay, now we can remove deprecations older than 2 ( ? 3? ) years!

I started to remove unsupported code. See related patches.

Change 449026 merged by jenkins-bot:
[pywikibot/core@master] [cleanup] Remove getParsedString Site method

https://gerrit.wikimedia.org/r/449026

Change 449025 merged by Mpaa:
[pywikibot/core@master] [cleanup] Remove unsupported removeImage and placeImage Page methods

https://gerrit.wikimedia.org/r/449025

MGChecker updated the task description. (Show Details)Sep 29 2018, 2:46 PM

Change 463775 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [cleanup] remove pre mw 1.14 code

https://gerrit.wikimedia.org/r/463775

D3r1ck01 moved this task from Backlog to Needs Review on the Pywikibot board.Nov 5 2018, 11:34 AM

Change 463775 merged by jenkins-bot:
[pywikibot/core@master] [cleanup] remove pre mw 1.14 code

https://gerrit.wikimedia.org/r/463775