Talk:Version lifecycle

Archive

Previous page history was archived for backup purposes at Talk:Version lifecycle/LQT Archive 1 on 2015-06-25.

There shouldn't be italics around the 1.41 release and end-of-life dates now that it's released, and 1.40 is now a legacy version since 1.41 became the new current version. It's semi-protected, so I can't edit it myself.

Good catch. I updated the page accordingly. Thanks a lot.

@Reedy: Since MW 1.39 is up for November 2022 shouldn't MW 1.35 be supported until November 2023 rather than September 2023 to have a year of support overlap as usual?

Spurred by a discussion elsewhere, I was comparing the info on this page to what's shown in Template:MWReleases, and it seems like there are some inconsistencies.

This page indicates that 1.35 is a LTS release, but {{MWReleases}} gives no indication of that, and strongly implies that 1.31 is still the current LTS, rather than the "legacy LTS" (whatever that means).

In fact, the templates in Category:MediaWiki version information templates (which drive the contents of the {{MWReleases}} box), have no entries for a "current" LTS release — only the {{MW legacy lts branch number}} is represented (which is 1.31).

I'm not quite clear on how {{MW legacy lts branch number}} ages out, upon the retirement of that release. Is there always a legacy LTS release? If so I suppose 1.35 would move to that spot next month, when 1.31 is EOL'd. (Seems a bit weird for the current stable release to also be the "legacy" LTS, tho. I would think 1.35 would stay as the current LTS until there's a next LTS.)

Regardless, it seems to me like there should be a Template:MW lts branch number (and friends), and it would currently point to 1.35. Having that template would allow {{MWReleases}} to detect and indicate that 1.35 is also an LTS release, the same way this page does. Or am I misinterpreting the release cycle somehow?

Yes, I think we should mark 1.35 as the current LTS alongside "stable", and indicate that 1.31 is legacy LTS (which just means there's a newer released LTS available).

Once 1.31 is EOL, then 1.35 will be both the LTS and legacy LTS...it's weird but yeah (at that point 1.36 would have taken over "stable").

I'm supportive of whatever template changes it takes to get there :-)

OK, I've created {{MW lts branch number}}, and have a {{MWReleases/sandbox}} version of the version-number box with edits applied. It should work like this, with the logic I modified in bold:

• Legacy LTS == LTS is accounted for, and will suppress the display of the (redundant) Legacy LTS
• Legacy LTS is the first version listed, iff != current LTS
• Same as before, if a legacy version != legacy LTS exists, it's listed after the legacy LTS
• The current LTS is now ALWAYS displayed. If current LTS == stable, it will be marked as both "(stable; LTS)"
• Otherwise, the stable version will be listed after the LTS, iff != current LTS
• If {{MW beta branch number}} is something other than "—", the beta version is listed
• Finally, the alpha/master is always listed

I also fixed the {{abbr}} transclusions for LTS, which were coming out backwards (as Long Term Support)... which I now see is due to the TemplateData for Template:Abbr having the fields reversed.

Legacy LTS is the first version listed, iff != current LTS

This seems a bit confusing. Although in practice legacy LTS releases will generally be our oldest release, it's listed first because it's old, not the other way around… Eh, it's probably OK.

I noticed that as well... the labels (legacy; LTS) next to the legacy releases are wrapped in <small></small>, but maybe the entire line(s) should be reduced / de-emphasized some... and/or, the current LTS or current stable (or both) could be enlarged and bolded, to make it clear they're the primary focus.

Or, barring that, it could go:

Stable releases

• Current stable (if != current LTS)
• Current LTS

Supported legacy releases

• Legacy LTS (iff != current LTS)
• Other legacy (if defined and != Legacy LTS)

Future releases

• current beta (if defined)
• current alpha/master

Though that's a lot of extra stuff to stick into what's meant to be a navbox, now that I look at it.

Yeah, let's keep things simpler and consistent?

Well, Izno rewriting the whole thing to use Template:Sidebar, in addition to just being a great idea generally, definitely helped with the consistency issues.

Something's gotta give, tho. Now that 1.36 is officially released, the sidebar shows:

MediaWiki
Older versions MediaWiki 1.31 (LTS) MediaWiki 1.35 (legacy) MediaWiki 1.36 (stable) MediaWiki 1.37 (alpha; git main)
Version lifecycle

Even more strongly implying that 1.31 is the current LTS, and that 1.35 is not an LTS, when in fact exactly the opposite is true for both of those things.

I'll work on porting my sandbox changes over to the new Template:sidebar version of the template, so that we can at least correctly indicate 1.35's status as an LTS release. Questions of ordering and emphasis can, I think, be addressed separately.

And I realize now I need to account for one more thing in the logic: when legacy (not stable) == current LTS (not legacy LTS).

...Now, that's really confusing: There's a legacy LTS version (1.31), and a legacy version (1.35)... but the legacy version is also an LTS version. 🤯

Yes, I suppose we've not hit that since this was all turned into "clever" templates.

I've updated Template:MWReleases/sandbox to incorporate my changes in with Izno's sandbox rewrite.

I also imported Wikipedia's Template:Hlist over here, and started using it to build the 'qualifiers' list. (Things like

• legacy
• stable
• LTS

next to the version.) The main reason being that Template:Hlist will automatically collapse empty arguments, which makes it a lot easier to construct a list out of conditionally-visible items.

Originally Izno had the "Older versions" link as the first bullet item in the list. That seemed weird to me (you can see it at the live Template:MWReleases), so I made it a separate sidebar item of its own, above the bullet list. I'd be quite happy to move it to the bottom of the sidebar, though, even though it'd be "out of order". I don't think it really needs to lead off the sidebar content at all.

Anyway, review or comment appreciated. Looks like the next thing to tackle is the {{MW release status}} header, which doesn't currently support "lts" as a status, and as a result is also hiding 1.35's LTS status:

*sigh*

Also, way to ignore my class=inline there, Template:Hlist. Maybe I should've used {{=}}, to hide it from Flow.

I've just seen this topic after making a related change to the Download page: see Topic:W9y3p9bik5syyn0v.

I wasn't bold enough to create a "MW current lts release number" template (which was clearly missing). I didn't spot FeRDNYC's "MW lts branch number" template because it's named differently to the others.

Anyway, I won't make any further changes now! And apologies if I didn't get it right.

"I didn't spot FeRDNYC's "MW lts branch number" template because it's named differently to the others."

Is it? It wasn't intended to be! Or do you just mean that I was lazy and only created the single "branch number" template and not the others, since I only needed the one for MWReleases? That was entirely just me doing half a task, the rest of the template set should absolutely be created IMHO.

And thanks for updating the download page, I had noticed that was showing 1.35 as LTS but didn't realize it was a recent change.

By all means, don't stop on my account if there are any other edits you're interested in making. I work pretty much in the open, if I'm updating a template the edits will either be live or, if they're more involved, in the sandbox. Either way, the more hands and eyes the merrier.

Thanks. I might get back to this some time, though it looks like it's under control. The Lua idea sounds good, as hopefully once it's been thought through properly it won't need to be changed. The current template structure is Byzantine, especially with the translate tags and Template:Void.

I didn't find your template because there is Template:MW stable release number, Template:MW legacy release number, and Template:MW legacy lts release number. I was looking for "release number" here but yours is Template:MW lts branch number.

@Jonathan3 The templates are byzantine, and I really don't understand why they're still in use (and, what's more, what we "probably want to use" according to the Module:Version docs ) when there's a perfectly good Module:Version already, which all of those templates just call.

Seems like we could replace all of the template transclusions with direct {{#invoke:Version}} calls, and things would at least be slightly less obtuse.

Maybe it's a caching thing? I could see how perhaps the results of an #invoke aren't cached, but the transclusion result for a template is. I imagine that would make the templates significantly less expensive than direct module calls. But I have no idea if that's the reason, or even if it's true; it's just the only thing I can come up with off the top of my head.

(And it'd be nice if, whatever the reason, it was actually provided when recommending use of the templates over direct calls in Module:Version/doc. In fact, I just added a Wikipedia-style ^[why?] after that unexplained recommendation.)

I'll create those missing {{MW lts foo}} templates now, so at least the full set is available.

Okay, all of the following are now valid transclusions:

• {{MW lts branch number}} => 1.35
• {{MW lts release number}} => 1.35.2
• {{MW lts release date}} => 2021-04-08
• {{MW lts release git}} => REL1_35
• {{MW lts release link}} => mediawiki-1.35.2.tar.gz
• {{MW lts release link zip}} => mediawiki-1.35.2.zip

we should just automate the whole table using Module:Version

Can we move release statuses ("current version", "legacy version", etc.) into a translatable template?

These edits waste translation time and resources.

Sure, why not?

Tbh, we should just automate the whole table using Module:Version.

Did not think of that. Sure, go for it!

Hi i have a question when the lifecycle of 1.3.1 will end?

in the page is written june, but the 1.3.5 has been released at the end of september 2020, plus we had proplem before with the gzip not working on windows and after with the bugged installer, in teory we should have an year of support to switch to the new version, i'm asking beacause due to the mass change i have to rewrite both my template and my extension from scratch and i need more time

1.31 will go end-of-life at the end of June, see the announcement. I would recommend you subscribe to the mediawiki-announce list for announcements like this :)

Hi @Legoktm as i said myself and you can read on my previous topic, i've just read the page and i know that actually the support should stop at the end of june, but taking in consideration that version 1.35 has been usable from the end of january with workaround (first the gzip not working on windows, after the bug of the encoder: Topic:Vzxi8uroe2eo23gk) or from the release of the 1.35.2 as it is, we have around 5 month of support to switch instead of the year that we should have: Version lifecycle#Release policy.

At least you can support the 1.31 till the end of september following the extension from may to june that happened with the passage from 1.23 to 1.27

@Selven In case you didn't see, in the 1.36.0 release announcement we just sent out we said "1.31 will get best-efforts extra support until the end of September 2021". Hope this helps.

Version lifecycle says yes, but Download don't. Who is wright?

Fixed now I think?

The Release timeline still references Bugzilla (“Create X.XX version in bugzilla”). Could someone update it to the new workflow (I think it includes at least creating mw-X.XY-release tag in Phabricator?)?

Good pick. Just changed this according to your suggestion. Still need someone to accept the change though.

I wrote X.XY (I may have been clearer) because MW-1.26-release has been created for the 1.25 release, not MW-1.25-release. This is why I asked for an update instead of doing it myself…

Why complicating things? Let them create whatever tag with the schema "mw-x.xx-release" whereas every x is filled with some number.

The rows’ first cells cannot be translated in the Release timeline section. This helps enforcing consistency for the R abbreviation (even if I would prefer being able to translate it), but forces every language to show weeks. I think the whole cell should be translatable.

Perhaps it should say REL-n weeks were weeks is actually translatable.

I just moved the weeks out of this cell to the introduction at the top. This saves us from having heaps of extra tags. Again a good finding. Thanks!

I believe when people see the information about 1.19, 1.21 - 1.23 they will ask: "Hmm... what happened to 1.20? Was this version accidentally forgotten? Was it purposely removed and for what reason?" - So having it in the list avoids this. Also having 1.18 conveys the message that this version and any prior version is obsolete.

Someone else said that they thought the versions needed to be cleaned up. I'm not about to get into an edit war here, but it would be good if you could subscribe to wikitech-l and be able to join in when appropriate.

Oh my g... - this was on the mailing list? This is pretty unexpected. Well, it would have been nice to have some sort of reference in the summary to this to make it easier finding out about the rationale behind it. Probably I would not have touched the page. This is however definitively not worth an edit war. Rather have people wondering about this page's content.

If you see the thread link it from this talk or an edit summary please.