Page MenuHomePhabricator

Remove manifest_version 2 from REL1_28
Closed, ResolvedPublic

Description

We (I) didn't have time to finish manifest_version 2 in time for REL1_28, and as currently stands provides no benefit to users except uncessarily breaking back-compat with older versions. We should remove it from REL1_28 until it is finished in REL1_29 and stabilized.

Details

Related Gerrit Patches:

Event Timeline

Legoktm created this task.Nov 2 2016, 12:02 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 2 2016, 12:02 AM
Reedy awarded a token.Nov 2 2016, 12:05 AM

What're we doing about extensions?

There's a couple actually making use of features... Mostly "path": true and such...

For path: true we can go back to the old hack of using a callback and determining the directory in PHP...

Krinkle added a subscriber: Krinkle.EditedNov 2 2016, 12:55 AM

Per T149759, the new features in MediaWiki master enabled via manifest_version 2 are already being used by some extensions and provide a better interface that we agree is generally preferred going forward (Right?) - something we want to document and encourage adoption of.

@Legoktm: Is it correct to assume these new features are stable and the only reason to keep them out of 1.28 is because we plan to add more features before marking version 2?

In that case I think, as long as MediaWiki supports both v1 and v2 anyway, I propose we finalise version 2 as-is (with only minor changes while 1.28 is going through beta and release-candidate phases) for REL1_28 and roll any additional features in master under "v3" going forward.

Thoughts?

Should this block the tagging of rc.0 until either manifest_version 2 is removed or a decision is made on @Krinkle 's suggestion?

Reedy added a comment.Nov 2 2016, 11:48 PM

Should this block the tagging of rc.0 until either manifest_version 2 is removed or a decision is made on @Krinkle 's suggestion?

I'd like to see what @Legoktm has to say. I know he's somewhat busy AFK with school atm.. But should reply "soon" hopefully...

@thcipriani Do you have an idea when you'd ideally like to tag it by?

Stalled T149759 till we decide how to proceed. Don't mind fixing up (most) of them, but don't really want to do the work if we're gonna keep manifest_version 2 as is in REL1_28

@thcipriani Do you have an idea when you'd ideally like to tag it by?

I had the deadline to tag/release 1.28.0-rc.0 today and did so:

https://lists.wikimedia.org/pipermail/mediawiki-announce/2016-November/000201.html

Probably still possible for rc.1? Unclear on what the policy for big changes is at this point.

Reedy added a comment.Nov 3 2016, 12:15 AM

@thcipriani Do you have an idea when you'd ideally like to tag it by?

I had the deadline to tag/release 1.28.0-rc.0 today and did so:
https://lists.wikimedia.org/pipermail/mediawiki-announce/2016-November/000201.html
Probably still possible for rc.1? Unclear on what the policy for big changes is at this point.

Ah ok, then, fine by me. Not a huge deal.

I believe, no big changes (ie features) should be introduced... Removing/disabling or even fixing broken/incomplete features is somewhat fair game... And should be done as appropriate

Per T149759, the new features in MediaWiki master enabled via manifest_version 2 are already being used by some extensions and provide a better interface that we agree is generally preferred going forward (Right?) - something we want to document and encourage adoption of.

Yes, but the only change that is actually useful is T100956. And currently there are one or two extensions that actually use it. The main change in T133626 hasn't been taken advantage of yet.

@Legoktm: Is it correct to assume these new features are stable and the only reason to keep them out of 1.28 is because we plan to add more features before marking version 2?

Yes. The main change left specifically is T133627.

In that case I think, as long as MediaWiki supports both v1 and v2 anyway, I propose we finalise version 2 as-is (with only minor changes while 1.28 is going through beta and release-candidate phases) for REL1_28 and roll any additional features in master under "v3" going forward.

I don't think it's overly problematic to support from the MW side - I'm mostly concerned that it's a breaking change (drops pre 1.28 support) for very little to no benefit.

Reedy added a comment.Nov 3 2016, 12:57 AM
  • BlockAndNuke
  • timeline
  • TorBlock
  • TrustedXff

all make use of the path feature

Reverting them out will take a bit of effort, but not much in the grand scheme of things -- I'm happy to do if deemed necessray

Change 319676 had a related patch set uploaded (by Reedy):
Revert out Extension Registration manifest_version 2

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

Change 319676 merged by jenkins-bot:
Revert out Extension Registration manifest_version 2

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

Reedy closed this task as Resolved.Nov 10 2016, 9:56 PM
Reedy claimed this task.