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".

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.

In T75916#787907, @Aklapper wrote:

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

In T75916#789084, @Jdforrester-WMF 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?

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:

In T75916#789084, @Jdforrester-WMF 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?

In T75916#787907, @Aklapper wrote:

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

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)?

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

In T75916#793597, @Jdforrester-WMF wrote:

In T75916#792822, @Qgil wrote:

In T75916#789084, @Jdforrester-WMF 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.

In T75916#808898, @Aklapper wrote:

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.

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".

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.

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

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.

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:

• 1.19-release
• 1.23-release
• 1.24-release
• 1.25-release
• In the list view: https://phabricator.wikimedia.org/project/query/all/?after=1

So from my point of view we are done here.

In T75916#952762, @Aklapper wrote:

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.

In T75916#955248, @Aklapper wrote:

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.

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?

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

In T75916#959250, @Aklapper wrote:

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.

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.

In T75916#960085, @Legoktm wrote:

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