- Mentioned In
- T259402: parsoid in 1.35.0-rc.0 not updated, it includes vendor/wikimedia/parsoid/src/Utils/Diff.php which doesn't pass PHP lint
- Mentioned Here
- T261863: Release 1.35.0-rc.3
T259685: Zeroconf VisualEditor/Parsoid doesn't work on SQLite
T261044: Parsoid in MW 1.35 is not compatible with PHP 7.2.0 (uses array_key_first())
rGPAR12e8ebfdb156: Ensure Parsoid doesn't throw when <ref> is used w/o Cite installed
T260201: Parsoid REST API may not check access permissions of user
T256375: Release MW 1.35.0
T259430: Release 1.35.0-rc.1
T259402: parsoid in 1.35.0-rc.0 not updated, it includes vendor/wikimedia/parsoid/src/Utils/Diff.php which doesn't pass PHP lint
Well, I was going to give it some time "out with the beta testers" to find out if there are other bugs that want fixing in 1.35. We'll talk about this at team meeting today.
But at some point we should just retag our last alpha as 0.12.0, and if there are subsequent issues we'll move to 0.12.1 etc.
Yeah. Documentation fixes, maybe changing of default config flags (whose state is otherwise well tested).
I don't think we have an answer for "how many rc are we going to have?". From memory, numerous times we've only had one, and that's basically gone final. I was going to plan to potentially do one a week (depending on the amount/severity of changes that have landed), as building the tarball etc is pretty quick. It's the prep work that takes a lot longer (especially in the case of security releases)
I planned to do T259430: Release 1.35.0-rc.1 by latest mid august, but with the amount of changes already merged, I think I might go for this week to get it out for testing. So if you've any backported parsoid fixes, please feel free to tag a and bump versions in REL1_35 before say end of day Thursday.
IMHO, I don't see any reason we can't retag whatever version of parsoid as stable/0.12.0 for final (if necessary). The diff in this case should be pretty minimal, as it will mostly be composer.lock file changes in vendor, and easily otherwise verifiable changes like the version change in composer.json. It shouldn't be a large set of PHP changes (though a version string inside parsoid for parsoid would be fine), for example. The same thought for retagging MW RC as final with minimal changes like $wgVersion and RELEASE-NOTE fixes as appropriate.
If there's any bug fixes that have been identified, I think it's better to get those in an rc (for testing as mentioned). I've no idea offhand how much it's being installed/tested (maybe I should file a task about someone checking the pingbacks?), but I've not seen any particular bug reports come in either
We don't *plan* to land any more patches in REL1_35. I think the only thing that might qualify would be a showstopper/security bug, or some issue with our 'flagship' 1.35 feature, which is 'zero-configuration' install of VisualEditor+Parsoid/PHP. That latter bit is what I expect we might get some feedback from the field on, if anything.
I'm nominating T260201: Parsoid REST API may not check access permissions of user as a possible cherry-pick to the 0.12.0 branch.
EDIT: never mind, I'm confused. T260201 was a VE patch, and it was already picked to REL1_35. Nothing needs to be done in the Parsoid 0.12.0 branch.
Ok, we've got a pair of bug fix patches sitting on the REL1_35 branch, one for T261044: Parsoid in MW 1.35 is not compatible with PHP 7.2.0 (uses array_key_first()) and a more minor one for 12e8ebfdb1565728e5efe23d3d9fecb53ce00f16 (this later patch was also cherry-picked to the REL1_35 branch of VisualEditor for zero-config use). @Reedy should we wait to see if any more fixed trickle in (there's T259685: Zeroconf VisualEditor/Parsoid doesn't work on SQLite for instance) or should I go ahead and tag v0.12.0 now and prepare a patch to mediawiki-vendor? We can always bump to 0.12.1 if we find anyhing else.
So it depends what the resultant release timeline is like... If we do another RC, these fixes should be in there. Which means a release being tagged (whether as another alpha or as the 0.12.0 doesn't really matter in the grand scheme of things, obviously just if the latter and something else comes up, we'll need a 0.12.1. If it's another alpha, it may be just retagging a previous release. I don't think either way maks too much difference), and the vendor updates before that happens.
If you're happy enough at this point, feel free to make 0.12.0, and bump in the various places. That gets things on a level again (plus being more visible in the diff from 1.35.0-rc.2 of the changes), and we're not rushing to tag and bump stuff later. Like you say, if something else comes up later, we can always make a further release ontop, and bump as appropriate. It's not zero work, but it's not a huge effort either
I think at this point, I'd not be against another RC, if we can get other fixes nailed down. The last couple of RC have obviously highlighted a few issues that could've been large show stoppers (and of course, that's the point of the RC!). https://github.com/wikimedia/mediawiki/compare/1.35.0-rc.2...REL1_35 hasn't got much atm, but we know there's a couple of Parsoid bugs etc fixed (but not yet included due to tagging/etc), plus whatever else from the below that should be included
MW-1.35-release has currently 14 tasks marked as blockers. Past experience says that they all won't be, and some won't be fixed before the release. Need some help triaging those, untagging or setting priorities and poking teams as necessary.