Prepare for v0.13.0 release

[Xymph]

I'm working on maxlag support which brings about significant code changes, so it's good to first create a stable release of where we are now.

If @waldyrious continues to be unavailable that's okay, but in absence of another active collaborator that means I'll have to keep merging my own PRs, in spite of this repo's governance guidelines. I intend to wrap this up on Sunday July 4.

[Xymph]

aedd469 fixes a copy/paste mistake in commit 5044fd7

[waldyrious]

If @waldyrious continues to be unavailable that's okay, but in absence of another active collaborator that means I'll have to keep merging my own PRs, in spite of this repo's governance guidelines. I intend to wrap this up on Sunday July 4.

First, apologies for disappearing without notice. I was AFK for a few days. But you do raise a good point — I probably won't be able to properly review every change to this repo, either due to availability, or due to lack of technical background. I think it may be worth considering an amendment to the governance guidelines to clarify that if no feedback from other committers is available within, say, a week or two, a committer should be able to merge their own PRs. WDYT?

[Xymph]

First, apologies for disappearing without notice. I was AFK for a few days. But you do raise a good point — I probably won't be able to properly review every change to this repo, either due to availability, or due to lack of technical background. I think it may be worth considering an amendment to the governance guidelines to clarify that if no feedback from other committers is available within, say, a week or two, a committer should be able to merge their own PRs. WDYT?

I agree, adopting a one-week pause is good even for the original contributor (e.g. me) in case further thoughts emerge or something small catches one's eye (like the copy/paste fix above). But development on any repo shouldn't be stalled for a long time because no reviewer is around.

Would you like to reword the governance bullet point? Then I can copy it into my branch and include it in this PR.

[waldyrious]

Would you like to reword the governance bullet point? Then I can copy it into my branch and include it in this PR.

I wouldn't do it just for that change, which is orthogonal to this release. But since we're also discussing the CHANGELOG file contents, which does affect this PR, sure, I can work that in. Let's just wrap up the discussions above and I'll make a new PR with the guideline changes.

[Xymph]

I wouldn't do it just for that change, which is orthogonal to this release. But since we're also discussing the CHANGELOG file contents, which does affect this PR, sure, I can work that in. Let's just wrap up the discussions above and I'll make a new PR with the guideline changes.

Changelog updated. If you could update governance and we merge that PR before this one, it will still be in the next release. That July 4 date can been moved of course, that was just my initial target before this discussion.

[Xymph]

These last two commits are bit beyond release preparation, but since neither is critical code I couldn't be bothered to create a separate PR or two.

[Xymph]

Commit b65cad3 belatedly correlates the documentation with PR #100 and commit aedd469.

[waldyrious]

@Xymph I've opened #105. I believe some of the changes from this PR should go there. The remaining changes that aren't related to the release (aedd469, fafa2d8, 984b11c, a1a44fa and b65cad3) will probably be better in a separate PR for assorted minor fixes, IMHO. I'd be happy to split them out myself if that's OK with you.

[Xymph]

@Xymph I've opened #105. I believe some of the changes from this PR should go there. The remaining changes that aren't related to the release (aedd469, fafa2d8, 984b11c, a1a44fa and b65cad3) will probably be better in a separate PR for assorted minor fixes, IMHO. I'd be happy to split them out myself if that's OK with you.

They've added up along the (unforeseen) way indeed. I didn't mind having them hitch along this PR ride, but if you think it's better to split them off, then I trust your judgement (and equally relevantly, git skills 😄 ) to make those changes.

Edit: Let's delay the release date by 1+ days as needed and not rush this reorganization, btw.

[waldyrious]

Ok, the commits listed in my previous comment have been cherry-picked to #106. Once that one is merged, this PR's branch will be ready for a rebase and conflict resolution (which I'll take care of).

[Xymph]

Most changelog entries use past tense. Since you're going to rework/rebase this branch, perhaps you can append a 'd' to the first word in "Modernize token handling for..." ?
Along with updating the release date there, and in Readme.md too.

Let me know if I should take care of any steps here - I am curious to see how that rework/rebase is going to look.

[waldyrious]

Most changelog entries use past tense. Since you're going to rework/rebase this branch, perhaps you can append a 'd' to the first word in "Modernize token handling for..." ?

Done. I was going to suggest doing it in a separate PR alongside rewriting the other entries in the changelog that don't start with a verb, but since that's the only one that starts with a verb in the present tense, and is part of this version's changelog, I agree it's OK to include the suggested change in this PR.

Let me know if I should take care of any steps here - I am curious to see how that rework/rebase is going to look.

Actually, git did most of the work :) when I ran git rebase -i master, it automatically detected that most of the commits had already been integrated via #106, and only included commits c07dc9a and e2c026c for rebasing. I marked the latter for squashing into the former (since the dates for other releases and missing changelog content had already been added in #105), and while fixing the conflicts, I added the d and updated the release date. I'll push the rebased branch in a moment.

[Xymph]

A thought just popped up (I seem to be good at that lately... 😉 ) regarding #100: that change requires MediaWiki v1.27+. It may be wise to mention this in the changelog and/or the readme. I'll also note it in the release tag. My draft text for that:

This release modernizes token handling for API interactions, adds more debug logging, adds governance documentation, and collects minor improvements into a stable release. It requires MediaWiki v1.27 or newer.

WDYT?

[waldyrious]

Yeah, it makes sense to include that caveat both in the changelog and in the release notes. I'll go ahead and edit the changelog.

As for the release notes, they look great! What do you think about linking to the changelog, though, as convenience for those who'd want more details on those items? Maybe something like this:

For more details on these changes, including links to the corresponding pull requests, please check the Changelog.

[Xymph]

Yeah, it makes sense to include that caveat both in the changelog and in the release notes. I'll go ahead and edit the changelog.

And what do you think about the same remark in the Readme?

As for the release notes, they look great! What do you think about linking to the changelog, though, as convenience for those who'd want more details on those items? Maybe something like this:

Good idea, will do, with an anchor to the specific version.

[waldyrious]

And what do you think about the same remark in the Readme?

Makes sense, yeah. I'll add it in a moment.

[Xymph]

Fine, that's a wrap. I hope I don't have a belated insight tomorrow though. 😜

Wanna do the merging honors?

[waldyrious]

Sure, let's do it! Any later tweaks can be published as patch releases if needed ;)

[samwilson]

Great work on the new release! :-)

It doesn't seem to have updated on Packagist yet, maybe auto-updating isn't enabled? It looks like @galtomer is the maintainer there?

[Xymph]

Thanks @samwilson, then I suspect you're going to like the next release even more. 😄

Even if @galtomer isn't around to update manually, "Existing packages without auto-updating (GitHub/BitBucket hook) will be crawled once a week for updates." (under Update Schedule). The last-update timestamp in the right column of the package page is 2021-06-29. So let's wait and see?

[waldyrious]

What would it take to enable auto-updating, btw?

[Xymph]

What would it take to enable auto-updating, btw?

A few configuration steps by @galtomer appear to be needed. I don't have an account there and even then, I don't think I'd be able to modify someone else's entry.

[samwilson]

@galtomer could probably add @hamstar and anyone else as a maintainer for the package. (I'm not really sure how the package managed to get registered by a different user.)

[waldyrious]

He doesn't seem to be very active on GitHub. I'll try reaching out by email.

[waldyrious]

@Xymph, do you already have a profile on Packagist? If not, could you create one?

[Xymph]

@galtomer could probably add @hamstar and anyone else as a maintainer for the package. (I'm not really sure how the package managed to get registered by a different user.)

@hamstar hasn't been active here for many years, so that wouldn't help on Packagist.

@Xymph, do you already have a profile on Packagist? If not, could you create one?

Didn't (see above) but do now, and it's connected to GitHub. But for access to Wikimate there, I guess we still need assistance from @galtomer.

[Xymph]

Ah, the hook enabled an "Update now" button at the end of the right column and it's up to 0.13.0 now. Phew. So even if @galtomer wouldn't set up auto-updating, we're back in business now. 😃

I'm not really sure how the package managed to get registered by a different user.

Since packagist only uses publicly accessible tag info, it appears anyone who connects that service here can set up the package, and update it.

[waldyrious]

Great! In any case, I'll email @galtomer to ask if he'd be up for adding us as maintainers in Packagist. It's always best to have multiple people with access to avoid bottlenecks and improve the bus factor.