[go: nahoru, domu]

Jump to content

Talk:IOS version history: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Widespread copyvio: My inclination is to leave the highly-detailed stuff to the individual release pages, with just the highlights given here.
Line 83: Line 83:
::::::There's still an issue that if the tables are brought here, the article would be ~80% tables (if not more) and ~20% prose, even if we replace the release notes with links. And there's no links for the release notes to the first four versions of iOS, so those tables would be even longer. We ''could'' put all the tables at the end, but that doesn't feel quite right. Are you sure it's worth it to bring the tables here? The prose here could be ''significantly'' expanded, and I worry that if we add tables again, most of the editing attention will just go to them, instead of going into build a really solid, encyclopedic summary of major changes in each iOS version.
::::::There's still an issue that if the tables are brought here, the article would be ~80% tables (if not more) and ~20% prose, even if we replace the release notes with links. And there's no links for the release notes to the first four versions of iOS, so those tables would be even longer. We ''could'' put all the tables at the end, but that doesn't feel quite right. Are you sure it's worth it to bring the tables here? The prose here could be ''significantly'' expanded, and I worry that if we add tables again, most of the editing attention will just go to them, instead of going into build a really solid, encyclopedic summary of major changes in each iOS version.
::::::We don't list minor versions in [[Microsoft Windows]], for example. What I have in mind is something like [[Android version history]], but in prose (or list), rather than in tables. [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 02:56, 15 January 2023 (UTC)
::::::We don't list minor versions in [[Microsoft Windows]], for example. What I have in mind is something like [[Android version history]], but in prose (or list), rather than in tables. [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 02:56, 15 January 2023 (UTC)
:::::::My inclination is to have this page give, for each major release, the most significant features, with minor releases mentioned only for significant features that don't show up in the .0 release, and leave the details to the individual release page. (That would be my inclination for ''all'' version history pages.) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 03:43, 15 January 2023 (UTC)


== Requested move 4 December 2022 ==
== Requested move 4 December 2022 ==

Revision as of 03:43, 15 January 2023


"Final" and WP:CRYSTAL

It seems to me that, if WP:CRYSTAL means "don't say 'Expected to be the final release'", it should also mean "don't say 'Final release'", unless there's a citation in which Apple says "we will not ever put out another release of this major version, even if some 1337 h4xor figures out how to hack the release to make the phone explode and kill you". Guy Harris (talk) 22:15, 26 July 2022 (UTC)[reply]

Yeah, note the circumstances of the late update, but otherwise nothing is set in stone. Cards84664 02:16, 27 July 2022 (UTC)[reply]

iPadOS version history should be on a separate article.

Since iPadOS became a separate OS based on iOS, just like tvOS or watchOS it should be separated from iOS, so this article could focus on iPhone's iOS. LinuxPower (talk) 10:08, 18 October 2022 (UTC)[reply]

Agree. Apple release separate release notes for iPadOS, so they can be treated as distinct OSes. DFlhb (talk) 13:06, 4 December 2022 (UTC)[reply]

Operating system support table could be merged.

iPhone's main article has a similar table but with a different set of datas. That table was proposed to be split into a separate article. This table in this article feels a bit redundant and less relevant to iOS but more relevant to the iPhone series itself. If the proposed article will be made this table should be merged into that one. LinuxPower (talk) 11:33, 18 October 2022 (UTC)[reply]

Update: I removed the table entirely because the same can be found on iPhone's article so every data can be found there, which are mainly hardware related, unrelated to iOS itself (eg. launch prices for every iPhones). LinuxPower (talk) 22:26, 19 October 2022 (UTC)[reply]

Widespread copyvio

AFAIK, Apple's release notes are copyrighted. We should link to them, not copy-paste them here verbatim. Link to Apple's official site whenever possible, not a third-party site; and make sure to archive those pages since they'll likely be taken down after the next version is released.

macOS Ventura is a great example of how to release history tables very well (the table is also much more readable, and we should imitate its concision and color scheme). DFlhb (talk) 13:10, 4 December 2022 (UTC)[reply]

Given that it's not a single table cell, I'll list findings here:
  • The very first revision inserts verbatim copyvio of Apple's 1.1.1 release notes (material was taken from iPhone, but was added to that page after the MacRumors article came out). The release notes are short enough that they don't trip Earwig's detector, but they're copied in their entirety. Removed in this diff
  • This diff inserted Apple's official iPhone OS 2.1 release notes; this stayed for years, but the wording drifted, some phrases were still present verbatim (like "Improved email reliability, notably fetching email..."), removed in this diff.
  • Later, this diff introduced clear copyvio of this forum post; the insertions were cited to that same forum post, so it's clear the post came first; they were mostly removed in this diff.
  • More minor copyvio of Apple's official release notes: 2.2.1, 3.0.1, 4.2.9, 4.2.10, 4.3.1, 4.3.3, 4.3.4, 4.3.5
  • This diff inserted copyvio. So did this one (from here).
  • this diff introduces verbatim copyvio of Apple's notes, still present until days ago.
  • Likely copyvio already back in 2011.
  • The following were all present until days ago, but I haven't checked when they were added:
  • iOS 5: 5.0.1, two sentence are taken verbatim (but minor), 5.1, three sentences identical or almost (Photo Stream, "louder and clearer", podcast controls), 5.1.1, almost verbatim vio
  • iOS 6: clear vio (6.0.1, 6.1.5). A few are minor vios: 6.1.1, 6.1.2, 6.1.3 6.1.4.
  • iOS 7: vio (7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.1, 7.1.1, 7.1.2).
  • iOS 8: vio (8.1, 8.1.3, 8.2, 8.3, 8.4, 8.4.1). Two, 8.0 (China) and 8.1.2 are minor vio. Also 8.0.1 and 8.0.2.
  • iOS 9: vio (9.0, 9.0.1, 9.0.2, 9.1, 9.2, 9.3.1, 9.3.2).
  • iOS 10: vio (10.0, 10.0.2, 10.1, 10.1.1, 10.2). A few, 10.2.1 and 10.3 (podcasts, voiceover) are minor.
  • iOS 11: vio (11.0, 11.1, 11.1.1, 11.2, 11.2.5, 11.2.6, 11.3, 11.3.1, 11.4, 11.4.1). One, 11.1.2 is borderline.
Will keep adding as I check each version. Stopping at iOS 11. DFlhb (talk) 17:48, 31 December 2022 (UTC) (updated 22:12)[reply]
Remember also, as per Wikipedia:Copyright violations § Parts of article violate copyright, to add {{copyvio-revdel}} as appropriate, to get copyright violations purged from the page's edit history. Guy Harris (talk) 20:45, 31 December 2022 (UTC)[reply]
Thanks, didn't know about it. Will wait to do that until vios are cleared from the current version.
It seems the iPhone OS 1.1.1 copyvio was here since the very first revision of this page, and came from this 19 November 2007 diff of iPhone. It appears to be Apple's official release notes, shared by several outlets on 27 September 2007.[1][2]
As for my list, I stopped checking at iOS 11; it's too time-consuming, and I've already confirmed numerous issues; a quick skim also shows substantial vio for more recent iOS versions, including the most recent ones. A more time-efficient solution may be to nuke all release notes from the table entirely (I can do it if you agree; would also help with WP:NOTCHANGELOG), unless someone wants to take the time to rewrite & rescue them. DFlhb (talk) 22:12, 31 December 2022 (UTC)[reply]
Given that most if not all iOS major version articles have their own minor release tables, which appear to have a sytle more like that in the macOS major version articles - and given that, with copyright violations spread among a large number of edits, so that most edits to the page wuld be blanked - I think the "kill the detailed release notes" solution might be appropriate here. We might even want to reduce this page to a major release summary page similar to macOS version history, also killing the minor release tables. Guy Harris (talk) 23:09, 31 December 2022 (UTC)[reply]
Agree. I've removed the tables entirely, to bring things more in line with the macOS article. There's other good reasons to remove them: they're utterly useless to mobile users & blind (screen reader) users, and they're an uninteresting lists of numbers and features.
By my standards, this article could never pass GA-review without losing the tables. Hopefully the article can be recentered around encyclopedic synthesis and valuable context instead. DFlhb (talk) 03:50, 1 January 2023 (UTC)[reply]

History cleaned out and semi-protection applied. Please let me know if the copyvio continues. MER-C 04:44, 8 January 2023 (UTC)[reply]

Will do; thanks. Must have been quite tedious clearing all the revisions; thank you for your work! DFlhb (talk) 12:05, 8 January 2023 (UTC)[reply]
I am not happy with this. You guys just deleted a bunch of history those tables were really useful and now they are all gone. Also a bunch of revisions were destroyed in just a short amount of time. Probably won't do anything to say anything about this but I don't like this change at all. SSoto21 (talk) 16:39, 9 January 2023 (UTC)[reply]
That's just my opinion. Not sure if those tables really were a copyright violation or not. SSoto21 (talk) 17:25, 9 January 2023 (UTC)[reply]
I posted here a month ago, so people could look at it and rescue what they could, but people either missed it or thought "who cares, it's just release notes", and here we are.
More generally, this hoopla is a great reason not to have detailed changelogs on Wikipedia. They attract IP users that don't care about copyvio, and they're obscure enough that nobody caught it for 14 years (in fact, only made it worse over the years). That's why WP:CHANGELOG exists.
Imagine Apple lists 20 bullet points in their release notes for a given version; and there's also two changes Apple didn't mention. We paraphrase the twenty, and mention the two; but the "two" will get lost in the mix. Those two changes belong outside the table, in prose. So why not just have the tables link to Apple's release notes, instead of a close paraphrase?
And if what you're missing from the tables isn't the release notes, but the device compatibility info (fair enough), then feel free to bring back the hardware support tables. I agreed with someone else to delete, but two people isn't remotely a binding consensus. DFlhb (talk) 14:40, 12 January 2023 (UTC)[reply]
I actually looked at the Release tables for Mac OS Ventura and they looked clean and nice. We should have something like that here. Also, you make some good points about the tables. SSoto21 (talk) 00:51, 15 January 2023 (UTC)[reply]
In that case, it might make sense to keep the tables synced between this article and the version-specific articles, which would entail moving these tables to templates and embedding them. Do feel free to do so if you wish.
I changed the iOS 16 table to look like the Ventura one (see revision), but was reverted by an IP user, and no one participated in the subsequent discussions; feel free to bring that back.
There's still an issue that if the tables are brought here, the article would be ~80% tables (if not more) and ~20% prose, even if we replace the release notes with links. And there's no links for the release notes to the first four versions of iOS, so those tables would be even longer. We could put all the tables at the end, but that doesn't feel quite right. Are you sure it's worth it to bring the tables here? The prose here could be significantly expanded, and I worry that if we add tables again, most of the editing attention will just go to them, instead of going into build a really solid, encyclopedic summary of major changes in each iOS version.
We don't list minor versions in Microsoft Windows, for example. What I have in mind is something like Android version history, but in prose (or list), rather than in tables. DFlhb (talk) 02:56, 15 January 2023 (UTC)[reply]
My inclination is to have this page give, for each major release, the most significant features, with minor releases mentioned only for significant features that don't show up in the .0 release, and leave the details to the individual release page. (That would be my inclination for all version history pages.) Guy Harris (talk) 03:43, 15 January 2023 (UTC)[reply]

Requested move 4 December 2022

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: Formally closed so that a multi-move discussion can proceed. No such user (talk) 13:00, 23 December 2022 (UTC)[reply]

Excuse me, if those were the cases, clarify the reason Fedora Linux release history was not moved to Fedora Linux version history. @ least a WP:REDIRECT can be created. Thanks.197.238.26.201 (talk) 16:49, 1 January 2023 (UTC)[reply]

IOS version historyiOS release history – "Release history" sounds much more encyclopedic (more formal) than "version history". I don't believe WP:COMMONNAME applies here, since there's no "correct" term, (see below) it's just a matter of picking the most encyclopedic-sounding WP:TONE. That's squarely up to our own subjective editorial judgment, and we can't punt this away to external sources to decide for us; they're not encyclopedias, we are. DFlhb (talk) 13:20, 4 December 2022 (UTC); updated 12:16, 23 December 2022 (UTC) — Relisting. ModernDayTrilobite (talkcontribs) 20:15, 12 December 2022 (UTC)[reply]

This isn't the only "version history" page. I assume that all the others are also part of this move request? O.N.R. (talk) 06:38, 5 December 2022 (UTC)[reply]
I'd like them to be; if you know of a correct place to propose mass-moves like this, I'd love to know. DFlhb (talk) 06:39, 5 December 2022 (UTC)[reply]
I'm tentatively in opposition to a change because I feel there's a difference between "version" and "release". A version could be any update to a software product, while "release" suggests more of a major update - except these articles don't focus solely on major updates. Like you said, this is subjective, so my opinion is not to change it for now but I'd like to hear your thoughts. Herbfur (Eric, He/Him) (talk) 20:19, 15 December 2022 (UTC)[reply]
I gave some thought to this. While I was initially under the same impression ("release" being reserved to major versions), it seems incorrect. "Releases" refers to all publicly released updates (including semi-public, like developer betas), while "version" includes internal builds and commits (as in version control). At least that's how Software versioning frames it, and experts seem to agree: [3][4][5][6].
That seems to reflect industry use, even for minor updates: Mozilla says "release calendar" and "release notes"; Chrome uses the term "releases" (again even for minor updates); Apple says "software releases" and "release notes", and seems to use "version" to refer merely to the number itself; same with Debian ("The latest release is Debian 11.6"); same with Ubuntu (which also calls minor/point updates "releases"); same with Linux ("bugfix kernel releases"); same with LibreOffice ("bug fix releases"); Microsoft are a little atypical, and use "version" for major updates, but they still list major and minor updates under "release history" as the general topic, which is what is relevant to us. DFlhb (talk) 20:04, 19 December 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
  • No such user, Herbfur, Old Naval Rooftops: do I have participants' permission to start a new move request using the correct multi-page move template (WP:RMPM, so it gets listed on every affected page), to place that new template at WT:WikiProject Computing, and to move your comments to that new discussion? (with an italics note explaining what I did, and a link to this page revision, so the original context is clear?) I apologise for using the wrong move template; I believe this is the optimal way to move forward, and would allow us to reach all affected editors, so that whatever consensus we end up with, no editor will complain that they missed this by the time it's closed. DFlhb (talk) 12:36, 23 December 2022 (UTC)[reply]
    DFlhb: You certainly do not need our permission to start a new discussion. I'll close this one as "no consensus", so that you can use the multi-move template appropriately (it takes the bot an hour or so to unlist this one and list the new one) ; best, use this very page as the first one in the listing, so that the RM discussion happens below, and people will be aware of the context (and we do not have to move comments around). A brief notice at WT:WikiProject Computing will be sufficient. No such user (talk) 12:59, 23 December 2022 (UTC)[reply]
    Thanks a lot! This was solid advice. DFlhb (talk) 17:23, 23 December 2022 (UTC)[reply]

Requested move 23 December 2022

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: pages not moved. Arbitrarily0 (talk) 14:00, 31 December 2022 (UTC)[reply]


Propose moving all articles from "version history" to "release history".

More WP:COMMON: Please see both of these Google Ngrams, separated[1], and combined[2]. I know "release notes" is more common than "release history": but "release notes" refers to the list of changes that accompanies a specific release, while "release history" is the overview of all releases. The latter which is what we're looking for. (struck Dec 29th; see below)

Used by experts: in software engineering and in the published literature, "version history" tends to refer to the record of all changes made to an app, which includes internal, non-public builds (as in, version control). The term "release history" is typically used more specifically to refer to the timeline of official releases that have been made to the public, which is what interests us. The distinction is reflected, partly or fully, in these papers: [7][8][9] (I read the contents, not just the abstract). Also p.19 of this book, pp.32-33 of this book, pp.10, 144 of this book, and throughought this book

Used by industry: the term release doesn't just refer to major updates, it's used for minor updates too: Mozilla says "release calendar" and "release notes"; Chrome uses the term "releases" (again even for minor updates); Apple says "software releases" and "release notes", and seems to use "version" to refer merely to the number itself; same with Debian ("The latest release is Debian 11.6"); same with Ubuntu (which also calls minor/point updates "releases"); same with Linux ("bugfix kernel releases"); same with LibreOffice ("bug fix releases"); Microsoft list all updates, major and minor, under "release history" as the general topic. edit: found that Arm, Samba, and Malwarebytes also use the term. 04:46, 24 December 2022 (UTC)

"Release history" also just sounds better, and slightly more formal.

See the above discussion for previous context. DFlhb (talk) 17:19, 23 December 2022 (UTC)[reply]

  • @No such user @Herbfur @Old Naval Rooftops, pinging previous participants, just in case. DFlhb (talk) 17:21, 23 December 2022 (UTC)[reply]
  • Oppose – They're called software versions, not software releases (that's a different thing). The versions are what's being released, but we're documenting the versions being released and not the dates and times of the releases. I've also never heard of the term "release history" being used. InfiniteNexus (talk) 04:18, 24 December 2022 (UTC)[reply]
    Mind clarifying what you mean by that Wikilink? They are called software releases, which is where the term release lifecycle comes from (and a release lifecycle is not at all the same thing as a release history). DFlhb (talk) 04:56, 24 December 2022 (UTC)[reply]
    Software release life cycle refers to the development stages before a software product is released to the public (i.e. dev, beta). A "software release" would mean that the final version of a software product is being rolled out to the general public. Updates after that, we call those software versions, or software updates. InfiniteNexus (talk) 05:16, 24 December 2022 (UTC)[reply]
    I know what the lifecycle is; programming is my hobby (though sadly not my main career). The distinction you claim exists, does not exist, as shown by all the large corporations I linked above that use software release (or release, as a noun, not a verb) to refer to bug fix updates. I recommend you don't base your opinion on a poorly-sourced Wikipedia article: after you reach the release stage of the life cycle, you enter the maintenance phase, and issue maintenance releases (that's another poorly sourced article, but an accurate one). The life cycle argument is a tangent that doesn't address our issue at all. DFlhb (talk) 06:09, 24 December 2022 (UTC)[reply]
  • Leaning support for the reasons provided above. O.N.R. (talk) 05:08, 24 December 2022 (UTC)[reply]
  • Oppose - The first ngram provided contradicts the notion that "release history" is more common than "version history", it has to be combined with an unrelated term, "release notes" to make it seem higher. This ngram is much more reflective of actual usage, and release notes should not be a factor here because release notes and version history are not mutually exclusive terms. I went to the first three big Debian-based distros I could think of (Linux Mint, Ubuntu, Debian) and all three use "version" rather than "release" to describe their most recent versions. Once you strip out the unrelated but similar concepts of release notes and the release cycle and examine the actual proposed titles on their own merits, sources appear to support the current title structure over the proposed one. - Aoidh (talk) 08:26, 24 December 2022 (UTC)[reply]
    Linux Mint, Ubuntu, Debian From my reading, all three refer to their list of versions as "releases"?[10][11][12]. Though Mint does use both. DFlhb (talk) 21:43, 28 December 2022 (UTC)[reply]
    Depends on what page you're looking at, because Ubuntu's documentation also very specifically uses version as does your Debian link. Regardless it's kind of moot since "version history" is what is specifically being discussed rather than simply "version" compared to "release", and nothing presented supports a move to the proposed titles. - Aoidh (talk) 18:17, 29 December 2022 (UTC)[reply]
    Right; everyone agrees that version is the correct term to refer to a version number, as in your link. It's my preferred table header here too. But I think the confusion is my fault: in the proposal, I emphasize about how "industry" uses releases for minor versions, when I should have instead focused on the fact that I deliberately picked only links that show an overview of versions/releases, and they all prefer the term releases to versions in that specific context. I didn't just pick random links that contain the word releases (like... you did for "version" :) ). DFlhb (talk) 20:17, 29 December 2022 (UTC)[reply]
  • oppose there are multiple reasons for oppose, one of which is WP:COMMONNAME. Also "release history" is kind of shorthand for "version release history", so "version history" is actually more formal. Also per Infinite Nexus, and Aoidh. —usernamekiran (talk) 16:51, 24 December 2022 (UTC)[reply]
  • Oppose I know "release notes" is more common than "release history" and that's where the argument starts to fall. The Ngram provided has version history above release history with hits. Invalidates the entire argument. Also, because it sounds better is hardly a reason. WP:COMMON does not apply to every case provided here - it's a big assumption with costly consequences. – The Grid (talk) 21:55, 24 December 2022 (UTC)[reply]
  • Oppose per evidence above with no objection to separate proposals where a specific software package self-references itself as "release history". —Locke Coletc 22:20, 24 December 2022 (UTC)[reply]
  • Indifferent. No strong feelings one way or the other. SWinxy (talk) 23:23, 28 December 2022 (UTC)[reply]
  • Oppose as "release history" is not only the same as "version history" but also a shorthand for "version release history" so I'd still go with "version history". Giorgos456 (talk) 17:23, 29 December 2022 (UTC)[reply]
  • Comment: I regret bringing up Ngram, my most minor point, which requires judgment to interpret. After browsing through 10 pages of Google Books results for "version history", I found only a single result about software; the rest were about document version history (as in, Google Docs or SharePoint) or databases (as in, data nodes[3]), not software. Your mileage may vary. Given that, I think the industry survey I give is far more informative. I'll strike my point about WP:COMMON, and offer a new argument, in addition to my remaining two: "version history" is IMO the best fit for barebones WP:Lists, but "release history" fits better with what our articles actually contain (some release notes, context, etc). DFlhb (talk) 19:49, 29 December 2022 (UTC)[reply]
  • Oppose. This was a worthwhile discussion but the choice is between options of roughly equal merit. Given no compelling reason to change, the status quo should therefore remain. As has been noted, the proposal seems to motivated in large part by personal bias in the interpretation of the key terms. The given arguments to change regarding "industry" this-or-that are unconvincing. Perhaps not within whatever circles or company which has shaped the proposer's view but I think the terms "release" and "version" are more ambiguous in general usage than is being assuming. Jason Quinn (talk) 00:55, 30 December 2022 (UTC)[reply]

References

  1. ^ "release history,version history,release notes,version notes". Google Ngram. Retrieved 2022-12-24.
  2. ^ "release history+release notes,version history,version notes". Google Ngram. Retrieved 2022-12-24.
  3. ^ Douglas, Terry (2022-05-31). Replicated Data Management for Mobile Computing. Springer Nature. ISBN 978-3-031-02477-1. a version history is a directed graph in which each node is a version and each edge represents a causal dependency
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hardware support

I've changed the hardware support tables. The previous ones had unnecessary color (MOS:TABLE recommends against color for decorative purposes), and were unsustainable, since they would continuously expand along both horizontal and vertical axes. I think my version is more tidy & clean, and it also only grows in one dimension instead of two.

See comparison here: new table, and old table.

I propose we remove the first table: its "end of support" columns are now redundant, which means all the table adds is list of major versions and release dates (uninformative). Frankly, I'd also support just removing all three tables, since people can go on the articles for individual models to see the first & last supported version, and it would keep this page focused on iOS proper. DFlhb (talk) 04:19, 1 January 2023 (UTC)[reply]

I think we should remove all the tables relating to specific models' supported iOS versions. Back in 2021, they weren't part of this article, and the information was still available on specific devices' pages (ex: the iPad Air page) - I was on Wikibreak when they were added. I think we should revert to this, and the new tables, which I think are more concise and readable, can be added to the relevant device pages.Herbfur (Eric, He/Him) (talk) 22:23, 2 January 2023 (UTC)[reply]
Adding on, I just checked, and there are relevant tables with OS support info on the iPhone, iPod Touch, and iPad pages. Thus, I think the entire section is redundant and should be removed.Herbfur (Eric, He/Him) (talk) 22:25, 2 January 2023 (UTC)[reply]
Agreed DFlhb (talk) 22:35, 2 January 2023 (UTC)[reply]