What is the state of play for this?

We're looking at doing T259128: Release 1.35.0-rc.0 for the end of the week, so I'd appreciate it if RELEASE-NOTES-1.35 and any config in DefaultSettings.php is correctly annotated (ie if still experimental etc) if not done already.

Obviously this can change further for when T256375: Release MW 1.35.0 actually happens, as that will be a few weeks from now

Thanks!

In T257396#6344888, @Reedy wrote:

What is the state of play for this?

We're looking at doing T259128: Release 1.35.0-rc.0 for the end of the week, so I'd appreciate it if RELEASE-NOTES-1.35 and any config in DefaultSettings.php is correctly annotated (ie if still experimental etc) if not done already.

Obviously this can change further for when T256375: Release MW 1.35.0 actually happens, as that will be a few weeks from now

Thanks!

Sure, we will get the release notes fixed up.

There is one bug T257259: Watchlist Expiry: Add support to maintain behavior when moving pages [Medium] that I think needs to be fixed for 1.35. Without it, it's possible watchlist expiries will be wiped out whenever a page is moved. This will not be fixed and QA'd in time for rc.0 (which I think is okay?), but we should certainly have it done in time for 1.35 proper.

In T257396#6346221, @MusikAnimal wrote:

There is one bug T257259: Watchlist Expiry: Add support to maintain behavior when moving pages [Medium] that I think needs to be fixed for 1.35. Without it, it's possible watchlist expiries will be wiped out whenever a page is moved. This will not be fixed and QA'd in time for rc.0 (which I think is okay?), but we should certainly have it done in time for 1.35 proper.

Yeah, that's fine.

As long as RELEASE-NOTES and any accompanying documentation in say DefaultSettings (ie the $wg to turn it on and off) say the feature doesn't work properly/is experimental, that's good to go.

I'll probably call it out explicitly in the announcment as known "this isn't finished yet"

I have moved this ticket to our Kanban board, so we can more effectively track it.

Change 617527 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/core@master] Add disclaimer about experimental watchlist expiry in MW 1.35

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

Change 617432 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/core@REL1_35] Add disclaimer about experimental watchlist expiry in MW 1.35

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

Change 617527 abandoned by MusikAnimal:
[mediawiki/core@master] Add disclaimer about experimental watchlist expiry in MW 1.35

Reason:
only goes in REL1_35

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

Change 617527 restored by MusikAnimal:
[mediawiki/core@master] Add disclaimer about experimental watchlist expiry in MW 1.35

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

Change 617432 merged by jenkins-bot:
[mediawiki/core@REL1_35] Add disclaimer about experimental watchlist expiry in MW 1.35

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

Change 617527 merged by jenkins-bot:
[mediawiki/core@master] Add disclaimer about experimental watchlist expiry in MW 1.35

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

I've added a warning to https://www.mediawiki.org/wiki/Manual:$wgWatchlistExpiry

OOI, are you keeping track of the backports that need to happen?

A quick look at REL1_35 compared to master suggests there's a few that haven't (yet) been backported to REL1_35, but presumably do want doing

I was looking in reference to T259885: Release 1.35.0-rc.2, to see whether we should do a release this week or next (don't worry, I'm not asking you to hurridly backport numerous commits)

@Reedy we are backporting as we are merging to master(most of the time). What patches are you talking about? As far as I can tell there is only one missing from REL1_35 (8544cf1c2f).

Question/Help:
I've been using git log --oneline --cherry-pick --no-merges --author='\(musik\|hmonroy\|sam\|dmaza\)' origin/master...origin/REL1_35 to compare the branches, is there a simpler way to do that? That command gives me some duplicated commits that I'm not sure what it means (I'm not great with git)

In T257396#6397600, @dmaza wrote:

@Reedy we are backporting as we are merging to master(most of the time). What patches are you talking about? As far as I can tell there is only one missing from REL1_35 (8544cf1c2f).

I've just had a look and I can't actually see the commits I might've been talking about.

I'll remember to post hashes next time...

Between T261175: Test that nothing broke in MediaWiki 1.35 with watchlist expiry disabled [[4HR]] and this... Do you have an idea when you think you should be about done for 1.35? :)

In T257396#6412178, @Reedy wrote:

Between T261175: Test that nothing broke in MediaWiki 1.35 with watchlist expiry disabled [[4HR]] and this... Do you have an idea when you think you should be about done for 1.35? :)

Our plan is to start rolling this out to some wikis on Sept 14th (see T261005). Unless something goes terribly wrong we should be pencils down with a MVP on the week of the 7th. When is the official release of 1.35?

In T257396#6413928, @dmaza wrote:

In T257396#6412178, @Reedy wrote:

Between T261175: Test that nothing broke in MediaWiki 1.35 with watchlist expiry disabled [[4HR]] and this... Do you have an idea when you think you should be about done for 1.35? :)

Our plan is to start rolling this out to some wikis on Sept 14th (see T261005). Unless something goes terribly wrong we should be pencils down with a MVP on the week of the 7th. When is the official release of 1.35?

https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-June/000250.html said "We anticipate that MediaWiki 1.35 will be released at the beginning of August."

We only did the first RC at the start of August

Informally we were targetting the end of August...

In theory, it should've been out in June/July... :)

I think https://gerrit.wikimedia.org/r/c/mediawiki/core/+/624782 is the only true blocker for 1.35 release on our end. If we wait until afterwards, we have to go through a long deprecation process (though I see from the mailing lists this process is being disputed). Pinging @Reedy to make sure this gets seen, as I see this task was moved from the "Blocker" column.

That said, watchlist expiry as a feature will likely not be "stable" for 1.35.0, hence we can leave the release notes as-is, with the feature flag marked as EXPERIMENTAL. We will instead aim for 1.35.1. But again, the aforementioned patch is of concern given its changes to Core (unrelated to watchlist expiry) and it would be most ideal to get that in the initial LTS release.

FWIW, I moved it from being a blocker because as we'd discussed before as you mention, it could go for 1.35.1 etc. It wasn't something that *has* to work for .0

It's a hard one. I'm certainly not blaming yourselves, but 1.35 by all indications is late. Sure, that's understandable with COVID etc. But we shouldn't be letting this slip too far.

REL1_35 was basically branched nearly 2 months ago (July 2020, I think), and was due to be released in early August 2020 according to https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-June/000250.html

The first RC wasn't out till the end of July.

Oh, and the next batch of security/maintenance releases (1.31.9, 1.34.2 and 1.35.1 is 1.35.0 is already out) are only a couple of weeks away (due end of September to get it out for this quarter).

And then the one after being in December 2020...

1.34 is supposed to be end of life in November 2020.. Which we obviously cannot do until 1.35 is out.

That all being said, I see rMW6a898faed2b8: Add watchlist expiry support to applicable APIs (and backported into REL1_35 with rMWa638fa853c5b: Add watchlist expiry support to applicable APIs) introduced the "problematic" commit that https://gerrit.wikimedia.org/r/c/mediawiki/core/+/624782 is resolving.

I definitely agree not making a stable release with a change that wants reverting out/changing. Sure, it's not the best that it's happening so late into the process, but that's life.

We could make a breaking change in .1, but there'd have to be a pretty good reason to do that

Is there an actual mailing list discussion? Or just the comments on the task etc?

Is there anything else really blocking this being merged, and backported? And if the only affected extension is being fixed... As long as that is also backported, I'm not really seeing any major issue?

I certainly don't consider this to be a breaking change as per Ammarpad on the gerrit change, and as per above, it hasn't been released (beyond the RC) and therefore isn't part of a stable release.

I'm presuming Daniel didn't dig into the git blame to check when it was added (looking at the time, it was probably the end of his working day).

Maybe that's a sign that the commit message needs some tweaks; even though it's mentioned as a Follow-up, make it explicit in text. e.g. it was added to master and backported into REL1_35 in $commit, but is yet to be part of a stable release. Which should help fix Daniel's concerns/query, along with anyone else who happens to stumble on it later

Noting that patch, and it's backport to REL1_35 have been merged

@dmaza - Can you provide a summary of what ended up being deployed with the 1.35.0 release?

In T257396#6506650, @kaldari wrote:

@dmaza - Can you provide a summary of what ended up being deployed with the 1.35.0 release?

As features go, here is a summary of what we've added so far:

• New notification widget that allows for an expiry selection after a page has been added to your watchlist (T249259)
• Ability to select an expiration period when editing and choosing to watch the page. Same for action=watch (T245565)
• UI indication (Desktop and Mobile) that a page is being temporarily watched using a half-star, clock icon, or a tooltip (T248495, T250215, T250212)
• Ability to see all watched pages according to expiration date in editwatchlist (T250214)
• API support to accept an expiration date when adding a page to your watchlist via multiple endpoints (T248512, T248514)
• Support for actions like rollback, protect, move, delete. There is no way of selecting an expiration period if you are watching the page but if there is already one it will be handled accordingly

I'm thinking about doing T264906: 1.35.1 Maintenance Release? to clear up some loose ends...

What is the current position of watchlist expiry, and more so in 1.35? I know there's been a few backports, but wondering if we'd be able to consider it stable etc

We are pretty much done with development and slowly rolling it out to a few wikis. Technically it should be stable but we want to wait and see it enabled in a few mid-size wikis first (happening next week). When are you planning on doing 1.35.1?

No immediate rush. Probably before the end of the month though

@Reedy is there a set date for 1.35.1? We are ready to remove the "experimental warning" on this now.

Nope! No fixed date. I'm definitely going to go ahead with it, possibly next week as there's a few useful bugfixes in it

I'll make this task a blocker to T264906: 1.35.1 Maintenance Release?, so we can do it after you've removed the experimental warning and as such close this task to mark it done.

Obviously if any further bugs are found, and backports are applicable they can be merged into REL1_35, either before or after 1.35.1. Anything after 1.35.1 will come out in mid to late December as part of the next quarterly security release

Change 637126 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/core@master] Remove disclaimer about experimental watchlist expiry

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

Change 637126 merged by jenkins-bot:
[mediawiki/core@master] Remove disclaimer about experimental watchlist expiry

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

Change 643958 had a related patch set uploaded (by Reedy; owner: Dmaza):
[mediawiki/core@REL1_35] Remove disclaimer about experimental watchlist expiry

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

Change 643958 merged by jenkins-bot:
[mediawiki/core@REL1_35] Remove disclaimer about experimental watchlist expiry

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