Page MenuHomePhabricator

Rename MediaWiki release tags
Closed, ResolvedPublic

Description

In BugZilla, the MediaWiki product had milestones like "1.1 release", "1.20.x release" and "1.25.0 release" etc.

Individual MediaWiki extensions didn't have such a milestone, but we did have shared ones for extensions like "MW 1.18 version", "MW 1.14 version".

To avoid clashing with other project's release tags (see also T75899), we should rename the MediaWiki core ones to include "MediaWiki" or "MW".

While at it I'd like to propose merging the ones formerly for extensions to be the same (e.g. merge "1.24.0 release" and "MW 1.24 version" into "MediaWiki-1.24" or something like that.

Event Timeline

Krinkle created this task.Nov 25 2014, 7:39 PM
Krinkle raised the priority of this task from to Needs Triage.
Krinkle updated the task description. (Show Details)
Krinkle added a project: Phabricator.
Krinkle changed Security from none to None.
Krinkle added a subscriber: Krinkle.
Qgil triaged this task as Medium priority.Nov 25 2014, 8:52 PM
Qgil edited projects, added Project-Admins; removed Phabricator.
Qgil added subscribers: Aklapper, Qgil.

(Starting today, I'm moving all the tasks related to new/renamed projects to Project-Admins because the Phabricator backlog is getting really big)

You say "release tags", I CC @greg and @Jdforrester-WMF.

I strongly support renaming the generic MediaWiki Target Milestones.
I'm not convinced to give those MediaWiki extensions Target Milestones the same name though as that would cross-pollute when searching in all those MediaWiki-* projects we have now so I' rather go with some "MW-1.24.x-series" or such.
There is also a small (maybe neglectable?) differentiation between "must fix in MW core for the 1.25.0 tarball release" vs. "should fix in this MW extension at some point in the branch corresponding to MW core 1.25.x releases".

greg added a comment.Nov 26 2014, 6:26 PM

Individual MediaWiki extensions didn't have such a milestone, but we did have shared ones for extensions like "MW 1.18 version", "MW 1.14 version".

What was the purpose of those milestones? Where they for things that should be backported or for planning ("hope to get this done by then")?

@Aklapper: can you update the description of T100: Decide how to organize iterations and releases with the summary of what we did/planned (or point to a wiki page that describes it). That should probably be the place we work from to solve this issue.

I strongly support renaming the generic MediaWiki Target Milestones.
I'm not convinced to give those MediaWiki extensions Target Milestones the same name though as that would cross-pollute when searching in all those MediaWiki-* projects we have now so I' rather go with some "MW-1.24.x-series" or such.
There is also a small (maybe neglectable?) differentiation between "must fix in MW core for the 1.25.0 tarball release" vs. "should fix in this MW extension at some point in the branch corresponding to MW core 1.25.x releases".

Well, the union search of "MediaWiki" project && "MediaWiki-release-1.18" release tag won't contain any extension items (and v.v.) – is that not suitable? This is what we're doing with "WMF-deploy-2014-11-26_(MW1.25wmf10)".

Well, the union search of "MediaWiki" project &&

A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

What is clear is that the current cohabitation of MW-1.24-release and #mw_1.24_version is confusing. As a bug reporter or even as a casual extension developer, how am I supposed to know which one to use?

PS: also, I wonder why #1.24.0_release or MW-1.24-release won't render a proper label.

In T75916#792822, @Qgil wrote:

Well, the union search of "MediaWiki" project &&

A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

Oh, I assumed that the MW team were going to fix this the way we have for VisualEditor, Parsoid, Multimedia… are they not?

What is clear is that the current cohabitation of MW-1.24-release and #mw_1.24_version is confusing. As a bug reporter or even as a casual extension developer, how am I supposed to know which one to use?

I agree we should fix this by only having one.

PS: also, I wonder why #1.24.0_release or MW-1.24-release won't render a proper label.

Maybe projects' hashtags can't start with a number to get auto-linked?

I'm not convinced to give those MediaWiki extensions Target Milestones the same name though as that would cross-pollute when searching in all those MediaWiki-* projects we have now so I' rather go with some "MW-1.24.x-series" or such.

I think this is biased towards MediaWiki core. You'd need to create milestones for every extension, skin and other MediaWiki-related project that doesn't have its own release/versioning scheme. That seems like a waste. Using #MW_1.24_version (as we're already doing for extensions, one has to intersect with the relevant project) seems simple enough.

For projects with lots of sub projects (e.g. things formerly having their own BugZilla product, like MediaWiki core and VisualEditor) would use an umbrella project.

At the moment that involves manual double-tagging (though a triager would have queries to find untagged issues to clean up). But there's to be intent in upstream Phabricator to embrace umbrella projects as a native concept (e.g. projects being in a hierarchy where they're visible and queryable via their parents). – https://secure.phabricator.com/T3670

Qgil added a comment.Dec 2 2014, 8:30 AM

A venturous summary of this discussion could be:

  • Valid Tags for past, present, and future MediaWiki releases: #MW-1.24.x, #MW-1.24.0, #MW-1.24.1...
  • Valid Tags for past, present, and future MediaWiki weekly snapshots: WMF-deploy-2014-11-26-(1.25wmf10)...

These tags are equally applicable to core, extensions, and anything else.

A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

Thanks for the better wording; that is the one single reason why I wrote "cross-pollution" here, as long as subprojects in https://secure.phabricator.com/T3670 aren't available...

If adding (currently) 30 projects (all those previous components of MediaWiki core in Bugzilla) to a search query to get only get MediaWiki core tasks with that milestone isn't considered a huge hassle (do it once for that target milestone, save the custom query for yourself or share the search query URL on some wikipage) I'm definitely in for making the naming scheme between extensions and core for target milestones consistent.

I assume we still want to distinguish "1.47.0" (which would cover potentially everything that was fixed in all those 1.46wmfXY versions and hence included in the 1.47.0 tarball) from "1.47.x" (to mark stuff that should be fixed or has been fixed in 1.27.x tarball releases after the initial 1.47.0 release and has required backporting from 1.48wmfXY branches or git master)?

So "MediaWiki-1.47.0-release" and "MediaWiki-1.47.x-release" (literally, replace "47" by your favorite number though)?

Aklapper claimed this task.Dec 4 2014, 2:35 AM

I'm happy with this, for one. Let's do it.

Qgil awarded a token.Dec 4 2014, 10:59 AM
Aklapper raised the priority of this task from Medium to High.Dec 5 2014, 1:30 AM
demon added a subscriber: demon.Dec 5 2014, 1:39 AM
In T75916#792822, @Qgil wrote:

Well, the union search of "MediaWiki" project &&

A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

Oh, I assumed that the MW team were going to fix this the way we have for VisualEditor, Parsoid, Multimedia… are they not?

I'd really like us to tag every single MediaWiki core bug with a [MediaWiki] project. The various subprojects (-Database, -UnitTests, etc) would be generalized to not be MW-core specific.

So for a MediaWiki database bug you'd tag it with [MediaWiki] and [Database].

This would also allow us to do things like [CirrusSearch] [UnitTests].

But really this should be its own task.

So "MediaWiki-1.47.0-release" and "MediaWiki-1.47.x-release" (literally, replace "47" by your favorite number though)?

Whether we should have only "MediaWiki-1.47", or "MediaWiki-1.47.0" and "MediaWiki-1.47.x", is a separate from this task. But, personally, I think we should only have "MediaWiki-1.47". These tags are milestones, release targets. Not the version a bug report relates to, or whether a fix should be backported. I always found the .x ones strange in the milestones for MediaWiki core when we used BugZilla.

fbstj added a subscriber: fbstj.Dec 8 2014, 2:04 PM
Qgil added a comment.Dec 10 2014, 1:21 PM

I also think that one MediaWiki 1.47 target milestone is better than two. While a minority knows which one should be used where, the majority get puzzled whenever find the double 1.47.

I'm for applying the single tag for a single version, and then deal with the problems retrieving the right information, i.e. by sharing a saved search somewhere public for "All MediaWiki core tasks tagged for 1.47".

Qgil added a comment.Dec 12 2014, 9:44 AM

If we have a decision, I volunteer with the renaming itself. For some reason blocked tasks T75994 and T78140 bother me more than they should whenever I see them in backlogs. :)

Happy for us to go ahead with this.

Aklapper added a subscriber: Legoktm.

<tl;dr>: We now have four active "Target Milestone" release projects in Phabricator left, regarding the MW core (and to some extend MW extensions) world:

  • 1.19.x release
  • 1.23.x release
  • 1.24.0 release
  • 1.25.0 release

Way too long version for transparency (had to write this down anyway as this stuff can get confusing if I don't concentrate):

I've archived the past projects #1.23.0_release , #1.22.x_release, #1.22.0_release, #1.21.x_release, #1.21.0_release, #1.20.x_release, #1.20.0_release, #1.19.0_release, #1.18.x_release, #1.18.0_release (which somehow don't get autolinked here, sigh).

In the meantime, @Legoktm had archived the #MW_1.24_version and #MW_1.23_version projects (use for extensions before) and changed their (open and closed) tasks' TM projects to the generic TM projects #1.24.0_release ( we don't have a 1.24.x_release project) and #1.23.0_release (.0, which is archived now, but there were no open tasks anyway).

I archived #MW_1.22_version which was empty. In general the use of these target milestones in Bugzilla seems to have declined over the versions

I batch-edited those tasks having MW_1.99_version tags set to have 1.99.x_release tags now.

Then I archived #MW_1.19_version to #MW_1.21_version.

Left here: Drop the .x or .0 prefixes?

I'd drop the suffixes indeed. And also rename to mention "MW" or "MediaWiki" (with old name as additional hash-tag for back-compat and redirect). This to be less generic, and also because Phabricator doesn't support mentioning hash tags starting with a number.

fbstj added a comment.Dec 19 2014, 8:52 PM

I also support dropping and also prefixing with MW as there's more than just mediawiki that might require versions at some point

+1 to dropping the point release suffixes.

demon removed a subscriber: demon.Dec 19 2014, 10:12 PM

Urgh. So I wasn't aware that Phabricator doesn't support mentioning hash tags starting with a number. :(
However, when is that important? I'd expect people to edit the Projects when setting a milestone, not mention those exact milestone names in a comment instead.

Regarding an umbrella MediaWiki project, that's covered in T76942.

I've dropped the .x and .0 suffixes from those milestone projects still active. Active projects left are:

So from my point of view we are done here.

Urgh. So I wasn't aware that Phabricator doesn't support mentioning hash tags starting with a number. :(

Phabricator support aside, "1.24 release" is too generic. Let's rename them to include "MW" (or "MediaWiki")?

It is not too generic once we've fixed T76942.

It is not too generic once we've fixed T76942.

Association or hierarchy does not equal containment. Even when Phabricator supports parent project associations (umbrellas), they're still in a shared global namespace and are bound to clash with other software projects. Forcing projects other than MediaWiki them to either adopt needless variation (e.g. v123 instead of 123-release), or adopt the same kind of prefixes I'm proposing for MediaWiki release tags.

fbstj added a comment.Jan 5 2015, 4:11 PM

But what about when there is a task/bug which involves one of these tags (targeting it for a particular release) and another piece of software/library/etc which is targeted too?

Aklapper closed this task as Resolved.Jan 7 2015, 1:12 PM

I'm afraid that I don't understand the last two comments and I need a more concrete example of an existing problem. (In short: if you don't want non-MediaWiki results in your search results, don't put non-MediaWiki projects into your search criteria. There's no forcing to needless variation as any project can request creating new projects, and there's no forcing to adopt prefixes as there are no prefixes currently.)

I'm closing this ticket as resolved. Which still allows adding followup comments.

fbstj added a comment.EditedJan 7 2015, 2:41 PM

Ahh yeah, my problem can be solved by either doing MediaWiki + version number tags or doing version number + not MediaWiki tags (querying 'not in 'MediaWiki tag')

EDIT: after further comments, I would still support prefixing rather than multi-tagging

Krinkle added a comment.EditedJan 7 2015, 3:42 PM

I'm afraid that I don't understand the last two comments and I need a more concrete example of an existing problem. (In short: if you don't want non-MediaWiki results in your search results, don't put non-MediaWiki projects into your search criteria. [..]

I'm sorry but this is rather frustrating. What don't you understand? This has got nothing to do with search results. I'll try and repeat myself one more time in verbose bullet points.

  • All Phabricator projects share a common global namespace. They're not like nested directories. Associating umbrellla or parent projects does not change this (it'll always be project/1.25-release, it doesn't nest like project/mediawiki/1.25-release, the umbrella is just meta-data, not part of the identifier).
  • A 1.2.3-release pattern is too generic as it doesn't specify what project it is about and can't be adopted as Phabricator convention in general as it would clash with other projects. It assumes MediaWiki core it the only project we have. We have in fact about 100 others.
  • Other projects are already forced to adopt a different pattern. Maybe they'll use a different generic pattern (arms racing for every variation you can think of). E.g. Project A might use v1.2.3-release (prefix "v"), Project B might use Release 1.2.3 (the word "Release"), project C might use ProjectC-v1.2.3. All variations that either try to fight MediaWiki's version numbers or come up with their own non-generic pattern.
  • Therefore, let's agree on a non-generic pattern to use for all projects (e.g. ProductName-v1.2.3 seems sensible).
  • Now use that for MediaWiki as well (keeping the old names as additional-hashtag aliases for back-compat).

I disagree as I do not see the problem of "clashing" once you can explicitly search for MediaWiki core tasks only with that generic milestone. So with the given arguments I currently don't (yet?) see a need to identify that the generic 1.25 milestone tag should specifically refer to MediaWiki releases only.
If there are other projects forced to adopt some pattern, I'm happy to get aware of these projects and discuss why v1.2.3-release is better for them instead of 1.2.3-release.

Krinkle added a comment.EditedJan 7 2015, 4:05 PM

So if I understand correctly you're recommending we consider version milestones as "accidentally" indexed and browsable through Phabricator as projects.

Thus we'd have to disregard all features related to it (members, watchers, workboards, archiving, edit permissions, change feeds, ..).

Because if you'd archive v2.0 when Project A's v2.0 is finished, that says nothing about a Project B still at v1.9 that will have a v2.0 next year. (e.g. like Firefox 30 and Chrome 30, you'd have to abandon all features related to individual projects and treat them as individual-meaningless correlation keywords instead).

That seems like a big waste and compromise in overall usability of Phabricator (the link on task pages to e.g. 1.24 release would only be confusing for users as it'd provide a meaningless feed of unrelated projects). All only to try and gain what? Smaller number of projects overall?

I'm not saying we should have separate version milestones for MediaWiki Core and MediaWiki extensions that follow the same release versioning. It makes perfect sense to share one "MW 1.25 release" between those (as I originally recommended which is what prompted this whole thread). Those would use additional filters in searches for e.g. "MediaWiki" when interested in that one project. (E.g. the Cite extension doesn't have its own release process, it just follows MediaWiki). But I'm talking about projects not directly following MediaWiki's release process. E.g. OOjs, VisualEditor, CDB, and all other projects we have.

I agree with Krinkle and fbstj that the projects should be MediaWiki specific. Basically, there should be one project for a MediaWiki 2.0 Release and another for a Pywikibot 2.0 Release.

I agree with Krinkle and fbstj that the projects should be MediaWiki specific. Basically, there should be one project for a MediaWiki 2.0 Release and another for a Pywikibot 2.0 Release.

+1

Nemo_bis removed a subscriber: Nemo_bis.Jan 7 2015, 8:11 PM
MZMcBride reopened this task as Open.Jan 8 2015, 5:13 AM

This issue doesn't seem resolved.

Aklapper closed this task as Resolved.Jan 13 2015, 1:37 PM

Thanks for raising these very valid and convincing points and for your patience.

I have added "MW-"prefixes. They are slightly less discoverable as I didn't want more stuff cluttering the projects dropdown when you enter "MediaWiki" plus as the dropdown does not support colors yet (there is some upstream ticket about this), people might think that they describe the version they are running instead of the version the bug should get fixed for.

See https://phabricator.wikimedia.org/project/query/all/?after=MW for a list.

Ironically that prefix we had also used for extension target milestones in Bugzilla too, so there were also disabled "MW-1.18-version" style projects. I have renamed those to "MW-extension-1.18-version" style to have less confusion in project dropdowns.

All in all, it's a bit more confusing than I had naively anticipated. I am sorry for that.

Closing as resolved.