Page MenuHomePhabricator

Release parsoid 0.12.0 and bump it in REL1_35
Closed, ResolvedPublic


Somewhat related: for the next 1.35 RC I'd like to bump parsoid from 0.12.0-a23 to 0.12.0 and make it a proper 'non-alpha' release. We didn't quite manage that before the branch.

@cscott do you want any more changes in parsoid first or can we just retag 0.12.0-a23 as 0.12.0?

Event Timeline

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.

We have T259430: Release 1.35.0-rc.1 either at the end of this week or next week, so we can let -a23 go in that one and then tag 0.12.0?

That sounds reasonable. Maybe tag 0.12.0 a few days before releasing rc.2, in case there are other issues that come up as folks play with rc.0 and rc.1.

I think we should wait till the final release to tag a 0.12.0 once we are done with all the cherry-picking.

ssastry triaged this task as Medium priority.Aug 3 2020, 6:21 PM

I think the idea is that rc.2 may well be the final release?

I couldn't tell from how many rc candidates are expected. But final is "sometime in August 2020".

That's a @Reedy question.

I would suggest that we do the bump in the final rc. We should be aiming to have as few changes as possible between the last rc and the actual release.

I would suggest that we do the bump in the final rc. We should be aiming to have as few changes as possible between the last rc and the actual release.

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.

Fair enough!

Just put this as a sub task/blocker for T256375: Release MW 1.35.0. We can leave it for now, and then get it done later in the month when we're finalising the release itself

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!). 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.

I'm going to do T261863: Release 1.35.0-rc.3 today, and then probably aim to finish off T256375: Release MW 1.35.0 by next friday.

Doing this early next week would probably work for me if you wouldn't mind :)

Any chance of this happening this week?

ssastry raised the priority of this task from Medium to High.Sep 10 2020, 5:24 PM

Change 626717 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/vendor@REL1_35] Bump Parsoid to v0.12.0 for release

Change 626718 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@REL1_35] Bump Parsoid to v0.12.0 for release

Change 626717 merged by Jforrester:
[mediawiki/vendor@REL1_35] Bump Parsoid to v0.12.0 for release

Change 626718 merged by Jforrester:
[mediawiki/core@REL1_35] Bump Parsoid to v0.12.0 for release

ssastry assigned this task to Jdforrester-WMF.