Debian package release adds +dfsg to revision number, breaking version parsing

[tigerpaw28]

TFWiki.net recently had an upgrade that changed the reported version number from 1.19.5-1+deb7u1 to 1.19.20+dfsg-0+deb7u3. With the way the version parsing code breaks up the string, the revision number ends up being 20+dfsg, which fails to parse as a short. I think just truncating the revision number to the first two characters would solve this without breaking the library for other version number formats.

[CXuesong]

Related: #72

[CXuesong]

It seems from https://github.com/wikimedia/pywikibot/blob/master/pywikibot/tools/__init__.py, that PyWikiBot is discarding all the unparsable suffix when parsing MediaWiki version. Thus I'll do something similar.

[CXuesong]

Released v0.8.0-int.2.

[tigerpaw28]

Hi,

I upgraded to the specified pre-release version but I'm still seeing the "Invalid version number" error. I will investigate this further over the weekend if you haven't looked at it before then.

[CXuesong]

I've tried this on .NET Fiddle and it works: https://dotnetfiddle.net/Qt33ij

using System;
using WikiClientLibrary.Client;
using WikiClientLibrary.Sites;

using var client = new WikiClient();
var site = new WikiSite(client, "https://tfwiki.net/mediawiki/api.php");
await site.Initialization;
Console.WriteLine(site.SiteInfo.Version);

[tigerpaw28]

Agreed and I stand corrected. I must've been looking at the wrong logs.

However, there is a secondary issue that I believe to be related. After logging in, if I try to refresh a page: await page.RefreshAsync(PageQueryOptions.FetchContent);

then a null reference error is thrown at line 218 of Revision.cs: if (Slots.TryGetValue(RevisionSlot.MainSlotName, out var mainSlot))

I'm thinking it's related because Slots is an array of "RevisionSlots" and the revision number is what caused the initial problem.

I'll leave it to your judgement whether this should qualify as a new issue or can be resolved within this one.

[CXuesong]

Released bug fix in WCL v0.8.0-int3.

Btw I just noticed your site is on MW 1.19. Do you have plan for upgrading the MW version? If not, I'm considering running unit tests against TFWiki.

Recently FANDOM is upgrading the MW version of their sites to 1.33, and a lack of WCL tests running agaist MW 1.19 is the root cause of such regression.

[tigerpaw28]

No, we have no immediate plans for upgrading past MW 1.19. There are some challenges for us to upgrade any higher and I don't expect that we will deal with them any time soon. You may use it for running unit tests.

I've upgraded to the newest pre-release and was able to refresh a page and retrieve the content.

[CXuesong]

I've upgraded to the newest pre-release and was able to refresh a page and retrieve the content.

Glad that the problem has been fixed.

No, we have no immediate plans for upgrading past MW 1.19. There are some challenges for us to upgrade any higher and I don't expect that we will deal with them any time soon. You may use it for running unit tests.

@tigerpaw28 Okay thanks for the courtesy. Note that to fully execute the unit tests, I'll need to 1) login to TFWiki and 2) create a sandbox page so the unit test can edit it over and over again. The bot account is tfwiki:User:FuncGammaBot. Please raise it up were there to be any concerns.

[tigerpaw28]

I checked with our site admin before making my last comment and he had no concerns over you unit testing. I will let them know the account being used so that they don't think the activity is suspicious.

[CXuesong]

Thanks! I'll set up test cases before closing this issue, then.

[CXuesong]

I've added a couple of tests against TFWiki now and I'll close the issue.

Note that I'm not editing any page on GitHub Actions, since the agents used to run actions are very likely to be blocked from editing on various wiki sites. The edits are taken place during my local executions.