For what it's worth it seems to have been mentioned just once on the Telegram chat, referencing Qichwabase (which indeed uses it). I will ask if anyone else uses it.

In case it helps to gauge interest, a straw poll on the Telegram group suggested a 2/3 preference for regular point upgrades over LTS for Wikibase.Cloud.

As I understood it actually implementing this is now maybe in the hands of the Wikidata Platform Team and the motivation / nudging would move to Wikibase Reuse Team

Thanks, lets put it that way:
We abandoned that approach, started from scratch and build a pathway that worked. If this issue has no learning merit to you anymore, it can be closed - we're not "waiting" on it's solution.
Again, thanks for everything, best regards and closing this year & issue, Tim :)

@GreenReaper I think the honest answer is that we don't know yet. There is a product incentive to have more features consistent across the Wikibase Ecosystem (Wikidata, Cloud, Suite). What that means for WB Cloud and our update cadence is still TBD. Personally, I would like to see us reduce the effort required for us to do updates so we can do them more often. We did manage to spend some time on this 1.39 to 1.43 update to improve the update process. I'll update this task to be slightly clearer.

The core issue, per the title, is "I can't edit the metadata that I have on this file, only delete it" (in fact I didn't try deleting the item because I couldn't get it back and don't control Commons deletions, although it'd be possible to add a few likely deletions to check).

I was taking a look at how this works on Wikidata: I believe there this doesn't occur because the statement is removed by the Commons Delinker Bot (e.g. in this edit)

I suspect it's more the latter and it's congruent with having had Commons media files on Wikibase.cloud in the last year, long enough for a deletion to occur and the issue to be revealed.

I'll just take a quick look to triage if this seems to be a regression due to the update to MediaWiki 1.43 or if this is a long standing issue.

I was under the impression that Wikibase.cloud would track LTS releases, the last transition being MW 1.39 to 1.43; is that no longer the case (i.e. users will get to use MW 1.44 in 2026), or is it more a matter of reducing the delta for the next update by maintaining a live development branch? (I know there was one user seeking to use TemplateStyles, which is bundled from 1.44, but I guess that's not the reason...)

In case for when this gets picked up in the future (since wbcloud runs MediaWiki 1.43 now): there is an old Cloud API PR around for enabling using Vector 2022 and Minerva https://github.com/wbstack/api/pull/869

instructions for reproducing this quickly locally:

Has it? Isn't the ticket about also handling some special case for .wbaas.dev type domains ?

This has been done here

Did we do update skirmish on 3/12?

From what I can see:

"[SQLBagOStuff] SqlBagOStuff::handleDBError: ignoring connection error"

[SQLBagOStuff] DBError: Database is read-only: This wiki is currently read-only.

Shreya71703 closed https://github.com/wbstack/ui/pull/1029

One notable change with this upgrade is the phpunit package major version dependency update to v11. The last time this happened (upgrade to v9/v10) we had to adjust a lot of unit tests. Hopefully it's not as much this time.

While waiting for a train I took some crude notes about what I saw relevant from the upgrade guide. A hidden gem in those guides is the last section, where it links to a diff of the core app skeleton. I think it's healthy to try to adjust as much as it makes sense to that with each major version upgrade: https://github.com/laravel/laravel/compare/10.x...11.x

That makes sense to me.