Talk:iOS version history/Archive 7

This is an archive of past discussions about IOS version history. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

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)

– 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: [1][2][3] (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)

@No such user @Herbfur @Old Naval Rooftops, pinging previous participants, just in case. DFlhb (talk) 17:21, 23 December 2022 (UTC)
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)
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)
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)
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)
Leaning support for the reasons provided above. O.N.R. ^(talk) 05:08, 24 December 2022 (UTC)
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)
Linux Mint, Ubuntu, Debian From my reading, all three refer to their list of versions as "releases"?[4][5][6]. Though Mint does use both. DFlhb (talk) 21:43, 28 December 2022 (UTC)
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)
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)
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)
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)
Oppose per evidence above with no objection to separate proposals where a specific software package self-references itself as "release history". —Locke Cole • t • c 22:20, 24 December 2022 (UTC)
Indifferent. No strong feelings one way or the other. SWinxy (talk) 23:23, 28 December 2022 (UTC)
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)
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)
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)

References

^ "release history,version history,release notes,version notes". Google Ngram. Retrieved 2022-12-24.
^ "release history+release notes,version history,version notes". Google Ngram. Retrieved 2022-12-24.
^ 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)

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)

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)

Agreed DFlhb (talk) 22:35, 2 January 2023 (UTC)

You can’t copyright facts. The changelog becomes fact as soon as it is published. The wiping of the full iOS version history from Wikipedia is chilling and disgraceful.

Maybe Wikipedia isn’t the resource I thought it was. 2601:442:4500:DD40:2900:B71D:D27:E4BE (talk) 08:29, 21 January 2023 (UTC)

Anyone, at any time, can take it upon themselves to grab the old version (get it from archive.org or by asking admins), check which parts are verbatim copy/pastes, rewrite those parts, and add it back to this article once it is problem-free. That means you, or anyone else. This page isn't bothering anyone, no matter how many tables it has, and the world will keep going 'round' even without this page having a Good Article badge.

Note, this doesn't mean it's fine to bring back copyright violations unmodified; just rewrite them first. DFlhb (talk) 11:25, 21 January 2023 (UTC)

You can't copyright ideas but you can copyright individual expressions. Apple's wording is an expression of facts. ViperSnake151 Talk 19:07, 21 January 2023 (UTC)

Screenshots should be moved to a gallery

The way the screenshots are just in one big row look really out of place, and messes with the tables. I would argue the screenshots would be better served by a gallery at the bottm of the page. - Evelyn Marie (leave a message · contributions) 01:24, 23 January 2023 (UTC)

They're only in a big row because of the missing tables. Since those tables are collapsed, I think it'll look quite nice. Please wait until I'm done and see what you think then. DFlhb (talk) 01:52, 23 January 2023 (UTC)

Also, to explain why I brought them back: the pushback shows that people value these articles for their technical comprehensiveness, not their fancy prose. I can see the tables' utility, and given that there's no other website than Wikipedia that could reasonably host all this detail and be high-profile enough that it could be assumed to be reasonably accurate, we easily justify bending the rules a little. The high page views & immediate pushback are further justifications.

We should still always link to official release notes, so copyvio can be easily checked and nipped in the bud, and so people can see the full thing. DFlhb (talk) 02:19, 23 January 2023 (UTC)

@DFlhb: I am one of those people who wanted the tables back, haha. I put a lot of work into the tables in the past, I was the one who actually designed the iOS version table template and its version sibling. I also was one of the editors who tried wherever possible to avoid any potential copyright violations. I always tried my best to custom write the release notes for versions, but then I took a break from Wikipedia for a while, to the point where plagiarized release notes became the norm again, sadly. I'm glad you're going through the trouble of adding them back. Thank you. - Evelyn Marie (leave a message · contributions) 04:33, 23 January 2023 (UTC)

I'm done—this is a start, but it's too time-consuming. I'd appreciate if you could take over from here; the previous source code is here, and there's Earwig's tool. I'll also bring back the iPad product codes, since they're still relevant here for pre-iOS 13 versions. DFlhb (talk) 05:43, 23 January 2023 (UTC)

@DFlhb: I can try and bring back the tables for the rest of the versions, although they won't be added at a super quick pace, due to risk of burnout. I'll add them whenever I can though. - Evelyn Marie (leave a message · contributions) 23:55, 23 January 2023 (UTC)

I have to say that I'm happy now that the tables are coming back and they look better than ever. I also notices that the later release tables did not link to Apple's security notes while most of the older ones did. Looks like that's been fixed now. SSoto21 (talk) 15:34, 23 January 2023 (UTC)

Permanent deletion of this article's history – why? by whom?

I wonder who is responsible for the huge, permanent (!) deletion of the (almost) entire history of this article since its start of on 6 March 2008!?? We could almost assume that Apple itself is acting here by proxy people? Just a thought. -- ZH8000 (talk) 13:55, 7 May 2023 (UTC)

It was removed per WP:PROPERSPLIT, which expects a "good summary" to be present in the main article of any material in articles split from this one. The tables, in their current form, are more detailed here than on any of the sub-articles. ~UN6892 ^t_c 14:10, 7 May 2023 (UTC)

WP:NOTCHANGELOG was another reason they were removed given most of the info was not covered in third-party sources, though the splitting guideline was the primary reason this time, see the thread above. ~UN6892 ^t_c 14:19, 7 May 2023 (UTC)

That's a separate issue; the revisions were deleted per #Widespread copyvio, after my report. ZH8000, I have zero affiliation with Apple, don't see why Apple would want the changelogs deleted, and am maybe the most active editor at WP:APPLE so I can hardly be accused of anti-Apple bias. UN6892: I disagree on your interpretation; I view this article as the child article of both iOS and the iOS major release articles, the same way WP:NOTSTATS views this as a child article of this. This article's purpose was (IMO) to unburden iOS and its main-releases articles from overly detailed information that wouldn't interest most readers, again just like that NOTSTAT example, where this was split from that. (If the iOS major releases articles went through WP:FAC, I doubt the tables would be tolerated there.) I have a very slight preference for having them here rather than in the iOS major release articles; though not a strong opinion either way. DFlhb (talk) 14:24, 7 May 2023 (UTC)

Note that I have no strong opinion on this, and doing it the other way around also makes sense (as Guy Harris prefers). Would welcome other opinions, and I'll note that my "NOTSTAT interpretation of NOTCHANGELOG" is unconventional and shouldn't be assigned much weight. But these tables definitely shouldn't be duplicated in two places. DFlhb (talk) 08:49, 13 May 2023 (UTC)

Looks like we're now up to at least 3 vs. 1 on the "child article vs parent article" debate. Cool by me. Courtesy-pinging Pppery. DFlhb (talk) 08:22, 14 May 2023 (UTC)

Well, I'm personally not even convinced that the tables belong on the child articles as opposed to nowhere. But that's not something really worth getting into an extended argument over. * Pppery * _{it has begun...} 15:15, 14 May 2023 (UTC)

@ZH8000 It was due to the rampant copyright violations (see WP:CV) where editors to the page would pretty much copy-paste Apple's release notes to the release notes column. Not sure why the revisions at the very start of the page's history were deleted as well, but that was something an adminstrator decided. If you want to view old revisions, I'm pretty sure the Wayback Machine has a lot of saved copies. - Evelyn Marie (leave a message · contributions) 04:52, 9 May 2023 (UTC)

I'm against the deletion of this page, but if you delete this, we should delete MediaWiki version history and any page in Category:Software version histories too. — Preceding unsigned comment added by 213.255.79.164 (talk) 08:49, 23 May 2023 (UTC)

Pedantry

There is no reason to constantly request deletion of this very useful page other than pedantry. This is why I hate to ever participate in Wikipedia, because of the tendentious, egotistical pedants that love to delete anything useful. Yes, you who want to delete this page are a pedant. Loknar (talk) 11:01, 26 May 2023 (UTC)

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)

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)

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)

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.[7][8]

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)

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)

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)

@DFlhb let's be honest; every time that there is a reference to a security issue, iUsers feel ashamed and every reason is a good reason to remove it to leave the perception of their loved products as much secure as possible. 109.118.86.49 (talk) 10:55, 20 June 2023 (UTC)

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

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)

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)

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)

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)

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)

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)

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)

If I may be forgiven for posting so many comments, here's what I envision this article looking like if it were FA-class:

hatnotes to the main articles under each header, so those links are more prominent
under each heading, several paragraphs giving an overview of major changes, with the paragraphs grouping changes by theme (for example, a paragraph on multitasking, another on collaboration), to keep it very readable and avoid density
screenshots of the home page for each release, to illustrate the changes
no tables

Seems like that covers all the bases. DFlhb (talk) 03:55, 15 January 2023 (UTC)

Home page as in home screen? Guy Harris (talk) 04:35, 15 January 2023 (UTC)

Exactly; the same screenshots used in our version-specific articles. DFlhb (talk) 04:51, 15 January 2023 (UTC)

On January 24, I restored a "cleaned-up" table for iOS 7, which has since been rev-del'd as copyvio of https://ijunkie.com/ios-7-features/ (the iOS 9 table was also rev-del'd, but I didn't add that). I'd never heard of iJunkie, and didn't rely on it to redraft the table, so I checked. The iJunkie article is dated September 18, 2013, the exact release date of iOS 7. But it looks like the site simply didn't exist at that time. The specific article has also not been archived prior to February 2, after my edit. I also notice that the parts copyvio'd by iJunkie were not ones rewritten by me, but parts that have been in our article since 2013, and that I checked weren't copyvio before adding them back; so I'm certain they copied Wikipedia rather than the reverse. I'll note that I also systematically checked my additions using Earwig's tool, and made sure they came back negative.

JJMC89, I don't mind this, I just hope this doesn't happen across other articles. Article publication dates are extremely easy to alter; using any CMS, I can publish an article today and set its date to "3 January 2005" with just two clicks; it's something to be mindful about. Regardless, thanks for your good work, it's much appreciated — DFlhb (talk) 12:30, 29 April 2023 (UTC)

The issue wasn't just the iJunkie publication date, which I don't think was faked. The copied text was in Template:IOS 7 on 18 September 2013, so I missed it when I checked the article for the text since the template is now deleted. I've undone the revdel for the iOS 7 part. — JJMC89 (T·C) 22:01, 30 April 2023 (UTC)

Makes sense; thanks a lot for checking — DFlhb (talk) 22:10, 30 April 2023 (UTC)

Release notes need to be deleted

Regardless of whether or not the release notes are copyvios, they are not encyclopedic and do not meet Wikipedia's inclusion policy. In particular articles are not exhaustive logs of software updates: "Use reliable third-party (not self-published or official) sources in articles dealing with software updates to describe the versions listed or discussed in the article. Common sense must be applied with regard to the level of detail to be included." If you are collapsing the content by default (which should only be done to navigation templates, never to article content), that is a clear indication that the level of detail is excessive and unwarranted. Nosferattus (talk) 20:11, 14 April 2023 (UTC)

As the release notes were a clear violation of WP:NOTCHANGELOG and the encyclopedic information about the releases was already provided in the article prose, I went ahead and deleted the release note tables. If there is more information that needs to be provided in the article, please add it to the article prose and cite it to reliable third-party sources (not Apple release notes). Nosferattus (talk) 20:28, 14 April 2023 (UTC)

I will mention that the release tables you removed are still present in the individual OS articles, eg. iPhone OS 1, iPhone OS 2, etc. Also pinging @Chris Ssk, who reverted your changes at Firefox version history. ChromeGames (talk · contribs) 12:31, 16 April 2023 (UTC)

I'm repeating my comment from Wikipedia:Articles for deletion/Firefox version history (2nd nomination). These articles go beyond a changelogs. They show the history and evolution of the software and. If these articles are against policy then all articles in Category:Software version histories (and sections in most software articles) should be deleted and Wikipedia will be poorer because of it Chris Ssk _talk 21:16, 16 April 2023 (UTC)

@Chris Ssk: I didn't say anything about deleting any articles and no one is arguing that the information isn't useful. The problem is that the changelog tables are not encyclopedic and the Wikipedia community has decided by consensus that such changelog tables do not belong in Wikipedia articles (which are intended to be concise summaries of topics, not exhaustive sources of information). It doesn't matter if other articles already include them. The policy still applies. Nosferattus (talk) 22:00, 16 April 2023 (UTC)

@Nosferattus not encyclopedic? According to who's standard? You mention a consensus, but as these articles have existed for many years, and you are the only person on the planet to object to these articles' content, I would argue that you are breaking the consensus, not the literally entire other edit base for these articles. Daemonspudguy (talk) 02:50, 17 April 2023 (UTC)

@Daemonspudguy: I'm definitely not the only person that has objected to the content of these articles. Regardless, a policy is a policy. If you beleive that WP:NOTCHANGELOG is no longer based on consensus, you should get it changed. Pretending that it doesn't exist or apply isn't an option. Nosferattus (talk) 03:01, 17 April 2023 (UTC)

@Nosferattus I checked the AfD for Firefox version history, and I found that the vast majority of people has decided to keep. You and like 2 other people have said to delete. Daemonspudguy (talk) 03:07, 17 April 2023 (UTC)

you're also the only one to take the brash and (imho) irresponsible action of almost entirely blanking an article. Daemonspudguy (talk) 03:08, 17 April 2023 (UTC)

@Daemonspudguy: I have NEVER suggested deleting any articles related to version histories. Why are you making up lies about me? Do you really think it makes sense that this article is larger than Wikipedia's article on World War II? I'm sure you realize that we could include a lot more information about World War II, but we don't because it's an encyclopedia article, and it's supposed to be a short summary. Does that make sense to you? Nosferattus (talk) 21:42, 17 April 2023 (UTC)

@Nosferattus and I never said you did suggest deleting them. Why are you making up lies about me? Daemonspudguy (talk) 21:45, 17 April 2023 (UTC)

I know you are, but what am I? lol. I can tell this is going to be a productive conversation. Nosferattus (talk) 21:53, 17 April 2023 (UTC)

To chime in, just because the World War II article has less bytes, doesn't mean that this article alone is larger. Wikipedia has hundreds of articles on various World War II topics. The entire collection of World War II material on Wikipedia severely surpasses even this article. - Evelyn Marie (leave a message · contributions) 23:22, 4 May 2023 (UTC)

the majority of keep are invalid because there arugement was not based on policy and some accounts were single purpose. 1keyhole (talk) 21:54, 17 April 2023 (UTC)

by the same argument i could argue the delete are invalid as take one suggestion way out of context

WP:NOTCHANGELOG is NOT about banning such pages, its about avoiding other pages getting clogged down, your taking the literal of a text rather than the spirit of the rule, i am of the opinion WP:NOTCHANGELOG should be re-written to empisise this Popeter45 (talk) 23:16, 17 April 2023 (UTC)

I tried to delete them, separately from the copyvio, and the backlash was strong enough that I took the time to rewrite them and bring (most of) them back. I regret that I didn't just disregard the backlash and stick with policy (call me naive, I'd deserve it). The rough consensus back in October (between me, Guy_Harris, and I think SSoto21) was to make it look more like macOS version history, and move the tables to the main articles for each iOS release (keeping only the "useful" parts, i.e. version, release date & noteworthy changes, but getting rid of the full release notes). Still seems like the best option, and I'm still willing to implement it if you agree with it. DFlhb (talk) 14:46, 17 April 2023 (UTC) reworded word salad 17:38, 19 April 2023 (UTC)

The tables were not "exhaustive logs". They barely touched the surface of the changes included in iOS versions. They are a high-level overview, and were rewritten to be such back when DFlhb rewrote the tables. And I've also made significant efforts on my side to help the article not fall afoul of the changelog policy. It would be different if they were straight up copy pastes, but they aren't. They are unique takes on the changes included in iOS versions, with most of the not so major changes not included. With the previous backlash and consensus back in October regarding the removal of the tables, it was concluded that the tables are heavily wanted and desired, as they offer a high level overview of historic and current iOS versions that no other site can match, nor do any other sites have the reputation that Wikipedia does when it comes to information. Trying to change consensus again would require another major conversation, one that I'm quite frankly unwilling to participate in as its always the more negative editors nowadays that participate in these conversations when typical methods are used.

The summaries above the tables don't detail the major changes in each iOS version at all, they only go over device support and are basically repeats of one another, making them heavily useless. Yes, more sources need to be used throughout the article to satisfy secondary sourcing, but otherwise, based on consensus, the tables are wanted - Android version history had this exact same debate, and as well had an entire AfD discussion. That whole debate is the exact reason why WP's changelog policy even had its wording changed to begin with, to protect articles like Android version history from deletion, according to archive 45 on the WP:NOT talkpage. - Evelyn Marie (leave a message · contributions) 23:19, 4 May 2023 (UTC)

high-level overview ... were rewritten to be such: My only goal was removing the copyvio, though that did involve trimming almost 50% of the table text DFlhb (talk) 01:17, 5 May 2023 (UTC)

Another issue with the tables

I have looked through the entries for the first few iPhone OS/iOS releases and have found them to be more detailed than at each version's main article. We should have a summary at each version per WP:PROPERSPLIT so whether the tables should be included on Wikipedia (per WP:NOTCHANGELOG), they should not be on this page in their current form. ~UN6892 ^t_c 22:20, 6 May 2023 (UTC)

That's the consensus we reached back in January. If you want to know why it wasn't implemented: there was pushback to the deletion, so I sought to compromise by having the tables only be here, and removed from the main iOS articles. I reasoned that would be fine, since WP:NOTSTATS similarly explicitly allows 100% primary-sourced unencyclopedic articles like this as a way to unclutter the main articles. Only, when I deleted the tables from the dedicated iOS articles, that got reverted, so I just stopped and left to work on articles I cared more about. Further background is available in this comment of mine, which I deleted because I saw no chance of reaching solid (5+ editors) consensus on anything, given how few people were active here. (Also, I saw the version tables the same way I see tables in most articles: stuff I would hate to maintain, but if others care for them, "live and let live", not my business to delete.) DFlhb (talk) 22:56, 6 May 2023 (UTC)

I typically don't try to reinstate my edits unless I think my edits were clearly based in policies and guidelines, which I think they would be in this case. I think a short bit about changes in minor updates may be warranted, but a table definitely isn't. ~UN6892 ^t_c 23:45, 6 May 2023 (UTC)

Not sure which edits you're referring to; do you mean my removals from the individual articles? DFlhb (talk) 00:00, 7 May 2023 (UTC)

I meant removing the tables from this article. The tables themselves (if they were moved to another article) can probably be smaller given WP:NOTCHANGELOG expects RS coverage but that doesn't change that the tables should not be here in their present state. ~UN6892 ^t_c 00:02, 7 May 2023 (UTC)

Yeah. I'm used to AMPOL2, where my approach is generally discuss first (avoid "Bold/revert") and treating every page as if it was 0RR/1RR regardless of actual restriction. But agreed, I'll reinstate. Tables can be moved to the dedicated articles, heavily trimmed, and properly cited — DFlhb (talk) 00:22, 7 May 2023 (UTC)

Missing hardware support table?

Hi, this page used to have a nice hardware support table (https://wiki.riteme.site/w/index.php?title=IOS_version_history&oldid=1153922703#Hardware_support), which was previously in page https://wiki.riteme.site/w/index.php?title=List_of_iOS,_tvOS,_and_watchOS_devices&oldid=1096605967#Supported_iOS_releases (and even easier to read), now I can't find this table anywhere, could it be added back? It was very useful to estimate the lifespan of a released device. -- User34522938 (talk)

It was removed due to severe article bloat (it dramatically increased the post-expand include size) and the fact that the table at the top already serves of a sort of "support table" as it already shows "device end-of-life" as a column. It was fancy sure but used a heck of a lot of resources just to display. - Evelyn Marie (leave a message · contributions) 17:32, 16 May 2023 (UTC)

I'm not sure what your definition of "heck of a lot of resources" is, but regardless of that, it's a silly reason to remove information from an article (having said that, the inclusion of which chips are used in these devices is unnecessary information here so that could be removed to reduce those "lot of resources"). The "Device end-of-life" column does not provide the same information as these templates do. I've restored the article back to how it was. There should first be reached a consensus about this. --YannickFran (talk) 13:13, 6 June 2023 (UTC)

by "resources" i meant the post-expand include size. that should be kept to a minimum, and the inclusion of those templates alone bloated the include size by over 250,000 bytes. not to mention the device end-of life column in the top template *does* provide the same information as it shows next to the iOS version the devices that had device support end with that iOS version. stop adding back the device support section when it gives nothing of value to the reader and severely bloats the article size. - Evelyn Marie (leave a message · contributions) 02:28, 7 June 2023 (UTC)

The inclusion size is nowhere near remotely problematic, it's not an argument for removing information. And you keep repeating the argument that the end-of life column displays the same information. Where does that column shows which device started with which version of their respective OS? Where does that column shows how long these were supported? And even disregarding that, there is value in *how* data is displayed, even if its the same data twice. But that last point doesn't really matter because this isn't the same data. And yeah, no other version history article has tables like this. But there is also no other version history article about a peace of software where the version is as tied to the hardware it runs on as is the case with iOS. This too, is not an argument. Just because similar pages don't show such information doesn't mean any page should. --YannickFran (talk) 07:56, 7 June 2023 (UTC)

no offense intended, but the inclusion size is problematic, because any unnecessary content can increase the chance of this article surpassing that limit if and when the separate version tables are re-added, and if its surpassed, that means that the page will start glitching out. and we do not need a table showing how long a given version is supported for. when support for devices is dropped and said removal of device support is cited, it is displayed in the respective version's overview. it's already known that iOS 17 for example drops support for the iPhone 8 and X lineup. we do not need a massive table w checkmarks to know when a version no longer supports a given device. it is also pretty obvious that the iPhone X released with iOS 11, considering it was released in 2017. sorry but those support tables are staying removed. - Evelyn Marie (leave a message · contributions) 08:57, 7 June 2023 (UTC)

That argument also doesn't fly. If these tables should not be included because the version tables, that - and I can't stress this enough - do not exist will include that information, then the same goes for the overview table itself, everything in that table would also be included in the individual version tables. Future possible content that someone at some point may write is not an argument to not include information that is ready right now. And once more; this article is, even including the old full version tables, nowhere near reaching those limits. So no offense, but stop using those arguments because they make no sense. The size is not a problem (and if it ever would be, that's more a matter of splitting this article up rather than omitting information that you don't want to show) and neither is "repeating" information (with repeating between quotes, because it would be repeating information that isn't actually on this page).--YannickFran (talk) 07:29, 12 June 2023 (UTC)

my stance is firm. the device support tables aren't being added back. - Evelyn Marie (leave a message · contributions) 11:18, 14 June 2023 (UTC)

So just to sum it all up:

The tables would be too large in the post-expanded inclusion size according to you. The fact is that inclusion would add 238.961 bytes to an article of 438.928 bytes. Well and far below the 2.097.152 bytes limit. But also on the premis that when all version tables would be restored it would be to much, despite the fact that, based on old versions of this article with massive tables, it was still 1.2M bytes, still far away from the 2.1M limit). Regardless, these tables can be simplified to reduce that weight.
The tables would duplicate the Device end-of-life column according to you. The fact is that how information is presented can be valuable in and of itself, not that it matters because these tables both contain different information: the table does not show which was the first version supported on any given device or give an overview of the support duration, which the included tables do.
You say that the version tables would also include which version is supported on which device. The fact is that - again - how information is displayed is also relevant, but more important here: you're arguing information should not be included because information someone may add in the future might' also relay that information (but again, not in the same presentation).
This point also contradicts the existence of the Overview table, which has value to me, but by your logic should also be removed because its contents would also be available in the yet-to-be-added version tables.

This is clearly going nowhere, so I'm asking WP:3O. You don't seem to be willing to have an actual conversation on any of your points. Whenever an argument is leveled against it, you just come up with yet another argument (to the point of nonsense (e.g. removing information because future edits may include similar information)) without addressing any of the points made. --YannickFran (talk) 19:21, 14 June 2023 (UTC)

I guess this is just about the "Hardware Support" tables? There seems to be a larger debate going on here about tables on this page, so I'm not sure it quite makes sense to describe this as a "debate between two editors" where all that's needed is a third opinion to settle it. I'll weigh in as much as I can, but, just looking at a glance, I think it might be worth taking into account the larger conversation happening here, whatever I say.

Anyway, I don't think it's quite fair to just say that those tables are obviously "unnecessary" or "bloat." Obviously some people feel otherwise, and it's really a matter of opinion whether things like that belong in this sort of article.

That said, I think any tables like that should be well-supported by mostly-secondary sources, like anything else. Those Hardware Support tables didn't have any references at all, so it's hard for me to tell if that's true of the information in them. At least some of it does seem supportable by references from magazines in the main text of the article, but I'm not sure that all or even most of it is. If the ultimate source for it is just Apple's documentation, it makes it kind of hard to argue that the contents of the tables are notable enough to merit inclusion in the article, especially considering that the article is more of a narrative of iOS's development and reception over time than a detailed summary of what devices support what iOS version.

As a side note, I wonder if we could use some sort of broader policy discussion or clarification about these kinds of large reference tables. They seem to be a heated topic lately and a lot of people seem to be arguing past each other about them to some extent. There was an RfC on a similar issue a little while back that seems to have provoked great controversy and discontent. Mesocarp (talk) 00:54, 15 June 2023 (UTC)

Technical limitations should never be a reason to not include information, which is something that the Wikipedia Help page about this subject even calls out. If this article becomes too large because of its tables, it should be the version history tables that are moved to their own version specific article as is done for other pages (see Windows and macOS). However, this is not a concern at the moment.

While adding sources to the tables would be fine, I don’t agree that they must be third-party. Information about which device is supported by what OS is objective and similar tables don’t include sources either. It would be a welcome addition, but not a requirement. In my opinion, the reasons given to not restore these tables are inadequate.--2A02:A020:53:755D:E8B3:A296:3F13:37AC (talk) 17:32, 15 June 2023 (UTC)

I thought about it more, and I think you could make an argument from WP:NLIST that those Hardware Support tables should be allowed, even if they are only sourced from Apple's documentation, because the whole topic of the table (which phones support which iOS version) is widely covered in secondary sources. Does that have enough weight to counter WP:NOTACATALOG? I have no idea. So, in full, I really don't know to agree with here. Mesocarp (talk) 20:04, 15 June 2023 (UTC)

No. It does not. Having excessive detail on what version supports what is way too technical - and it does indeed violate WP:NOTCATALOG. - Evelyn Marie (leave a message · contributions) 04:09, 16 June 2023 (UTC)

3O: How is it "way too technical"? By what standard? Is there some accepted Wikipedia guidelines on technical is too technical to be included in a Wikipedia article? Brusquedandelion (talk) 09:19, 7 December 2023 (UTC)

WP:NOTACATALOG has nothing to do with this. If it did, many Wikipedia articles would have to be stripped of their tables. Brusquedandelion (talk) 09:20, 7 December 2023 (UTC)

@YannickFran i kindly ask you to stop reverting a change that was made weeks ago to the article. the table is redundant and unnecessary, and is not a focus of the article. So kindly stop edit warring and reinstating a useless change. Edit: The table also kinda violates WP:NOTCATALOG as well. Wikipedia is not a device support database. - Evelyn Marie (leave a message · contributions) 10:14, 30 June 2023 (UTC)

I kindly request you to stop acting as if this is your article and continously removing content that has been part of this article for years with not a single valid reason. WP:NOTCATALOG has nothing to do with these kinds of tables (which can be found all across Wikipedia), which you'd have known if you'd actually read those rules. The version tables on this page are closer related to that rule than the compatibility tables, and don't get me wrong, even that is one hell of a stretch. This is yet another example of you throwing a rule at this that has absolutely nothing to do with it. Please provide either a valid reason that can be discussed and let's come to a conclusion then, or just stop doing this.

And let me respond to the message you put in your edit: "this is a article focused on the development of iOS". No. It is not. This article is about its version history. Also, wasn't your argument just a few days ago that this was duplicating information on this page? So why was that information that it was duplicating here in the first place? This is yet another example of you throwing random arguments that make 0 sense at the wall to see what may or may not stick. If you'd like to read articles that actually are about the development of an OS, I'd like to refer you to Development of Windows XP and Vista. That's what an article "focused on the development of iOS" would look like. YannickFran (talk) 10:58, 30 June 2023 (UTC)

@YannickFran Any reasons I give you, you are more than likely going to outright disregard. I have been an editor of this page for literally years, and those tables with the abundance of checkmarks didn't exist until you added them in February of this year, so kindly stop with that - they were not part of the article for years, only a couple months maximum before they were removed due to the fact that they unnecessarily exploded the article size for no valid reason. Yes, there were device support tables, but none of them (aside from maybe the iPod touch table?) used checkmarks excessively. The version overview table already serves the same purpose via a secondary purpose (in that it shows when a device is end of lifed, along with its final iOS update), as I've said, and its been enhanced with more detailed information recently. Therefore, I do not agree with the tables, in their current checkmark-heavy state, existing on the article, due to the existence of the version overview table. - Evelyn Marie (leave a message · contributions) 11:48, 30 June 2023 (UTC)

Every reason you've given was citing either rules that do not apply to the type of content at all (like WP:NOTCATALOG), rules that it doesn't actualy violate (include size, etc.), things it doesn't do (repeat information, "[this article is about development therefor it is not relevant]") or are downright nonsensical ("[don't include information that future edits might add elsewhere]"). And you either keep repeating them without actually addressing the rebutals on those reasons or just pull another one out of nowhere. I feel arguing with you is pointless because you clearly aren't listening and just keep coming up with yet another argument as to why something you personally don't like shouldn't be here despite not having any objective reason for its removal. Case in point: accessibility.

Because it's absolutely rich that you now come with this "but they are not accessible" argument. Don't worry. They are. I would know. I need those tools. As a matter of fact, being accessible is partially - ironically - why they are the size that they are in the first place (your first argument that I've already pointed out is not actually a problem nor true). You could very easily have just checked if they are accessible. But at this point I can only assume that you don't actually have these concerns, because you're just throwing things at a wall to see what sticks and this happened to be another thing you could think of. Regardless, yet again this isn't even a reason to remove it. At worst you'd put a request for improvement on that with the accessibility concern at best you'd address these concerns yourself.

This is not your article. It doesn't matter how long you've been editing it. It's doesn't matter how much you've edited it. It doesn't matter how much you know about its subject. It doesn't belong to you. You're editing on Wikipedia, everyone can come in and improve these articles as they see fit. You are not the arbiter of what does and does not go. You're making no effort to actually resolve this and you're ignoring the opinions of others that try to do so.

Now, I gladly also admit I was wrong in how long these tables have been here, because indeed, they were only put on this page last year. After it was decided they'd be moved from the pages where they came from because they made more sense here. Much like the tvOS and iPadOS articles. With this article's entire history destroyed due to its copyvio it was kinda hard to check, but Wayback to the resque. Regardless, if "this was not on the page before" is something we should mind when making edits, Wikipedia might as well close shop right now.

Anyways it did get me to dig: I did went and look what was said about the removal of these tables originally in early January, and this comment was made about it by the person who deleted it (@DFlhb): "I agreed with someone else to delete, but two people isn't remotely a binding consensus". Who, by the way, also was the one to originally restore them in the first place 3 weeks later (on January 23rd), after which they have remained on this page for months until you started removing them on May 9th. So even your implications that they didn't use to be here and that your edit is the status quo is - yet again, and I cannot stress this enough - not true. YannickFran (talk) 17:30, 30 June 2023 (UTC)

It should also be noted that those templates were overly visual-heavy, which could be bad for people who are blind and require the use of a screen reader. Accessibility is important, even on encyclopedia platforms like Wikipedia, and those templates are downright awful when it comes to that. Screen readers, to work effectively, require captions, or alt text. Using checkmarks is not text. And to be honest I am unsure if the template that even generates the checkmark has alt text, but regardless, templates that are visually heavy should be avoided, or updated to rely more on strictly text. - Evelyn Marie (leave a message · contributions) 11:59, 30 June 2023 (UTC)

It's readable with screen readers (which read the column header every time you go left or right in a row, and the row header every time you go up or down a column), but could be better, and contains a lot of cruft. We should reduce it to 3 columns: model, first supported version, last supported version.

The Overview table was much worse for accessibility. For example, I go to the iOS 4 row. I go right, and it says: "June 21, 2010, initial release date". Then I go to the right, and it says: "4.2.1, latest version". But that's not the latest version; we list three because different devices had different end-of-life, but EOLs are mentioned further right, and it'll be unclear to people who use screen readers (4.2.10 was also unclear to me even though I can see fine). Non-header cells should also not be merged even when their contents are identical, since it'll only read it as the topmost, leftmost cell, and otherwise will skip over it instead of reading it. I've fixed the Overview table now. DFlhb (talk) 12:44, 1 July 2023 (UTC)

@Evelyn Marie: I can personally confirm that my screen reader has no problem with this table. It seems you didn't even bother checking before trying to make this argument, which suggests you are not engaging in good faith with @YannickFran but rather are just trying to invent new excuses to avoid letting YannickFran include the table, possibly due to a misguided belief that your years of editing this article means the article belongs to you (it does not). Brusquedandelion (talk) 09:28, 7 December 2023 (UTC)

3O: 25 kB is chump change; what is the problem?

If you think it is an eyesore- just don't look at it!

The table is useful information. It should be included. Brusquedandelion (talk) 09:13, 7 December 2023 (UTC)

@YannickFran: Respectfully, stop re-adding the template. There was no conensus to keep the tables and you are the only one arguing for the tables to stay by forcefully re-adding them to the page. They have no reason to exist on this page - The overview table, as previously discussed, already serves this purpose. Those hardware support templates do nothing except to repeat information in an arguably uglier manner. This is all I'm going to say on this subject. The tables stay gone - stop re-adding them without seeking consensus to re-add them. And another thing: Wikipedia's style guide literally says to avoid information-dense tables unless absolutely necessary. - Evelyn Harthbrooke (leave a message · contributions) 20:47, 4 December 2023 (UTC)

In this discussion alone I'm already not the only one arguing for these tables to remain on this page. Further down on this talk page, more people request for the restoration of the article prior to your removal of them. I am not the only one arguing for these tables to remain on this page (and let's keep that in mind: this is about content remaining, not adding). You on the other hand are the only one arguing for their removal. "This is all I'm going to say on this subject"? Fine by me if you don't want to discuss it, but then don't demand something is removed either. You have refused to actually discuss this in the past (and no, throwing random arguments at the wall and hoping one sticks is not "discussing"). But just throwing your hands up and going "this is the last thing I say so now anything I've said is set in stone and nobody else's opinion matters" is not how this works.

I've in the past asked you multiple times to actually discuss their removal but you have continued jumping around from one reason to another every time I pointed out that your reasons didn't make sense. You already made the claim that these tables were "too large" and caused the article to get to close to its inclusion size, but they very clearly don't and even if they did, at best that's an argument for an article split (and I'd argue that the version tables in that scenario are the one's that would have to be moved to their respective articles to reflect the structure for similar articles like the version histories for macOS, Windows 10 and others), not for their removal. Then you moved on to "these tables are not accessible" and that that somehow was grounds for their removal despite the fact that they very much are accessible (so you didn't even bother to check and tried to made an argument about something you don't know anything about). You've then argued that these tables duplicate the "End of life" column in the overview table. And sure, much like that table, these tables show which version was the last one to support a device. But sharing 1 data point doesn't make it duplication. These tables visualize both the progression and expansion of support as time goes on, and shows all versions of the supported OS by device. Even completely disregarding that, the same data represented differently is also a valuable resource. But again, that's assuming this data is on this page, which it's not. You then brought up that the version tables also include which versions of the OSes are supported on which device and thus "duplication". Except of course that first of all, difference in presentation matters and second, you are completely ignoring the fact that these version tables don't actually exist. Your argument there is that they might duplicate information that someone might add in the future. This also directly contradicts the existence of the Overview table which then also would be duplicating information (unless you want to argue that presentation matters). You decided to repeat these false claims once more when you began removing them again 2 week ago.

None of what I mention in the previous paragraph here is new information to you. I've already pointed all of this out to you. The above discussion is proof of that. What it also proves is that every time I did point this out, rather than acknowledge these arguments and explain what you were actually trying to say, you moved on to the next argument in line to see if anything you could think of might stick, or worse just went "no I want them gone end of discussion" and think that means you have a consensus. If you read up, you'll also notice that the original deletion was done without consensus. You don't get to say "I removed them and since I disagree with everyone else that they should stay there is no consensus for them to stay". That is - again - not how it works.

And now you come with what I can quiet frankly only describe as a "bullshit argument" that they are an "eyesore"? Please point me to the Wikipedia guidelines that explain when a table is an eyesore and how that is grounds for the removal of useful information. This also goes, once again, to show that you don't actually have a rational argument on why these tables shouldn't be here. If you don't like what these tables look like, feel free to either update their visuals yourself or add a template requesting improvements to the content (but then again, these tables are already built with various Wikipedia templates that are specifically designed for these kind of things). You personally disliking what a table looks like is not a reason for their removal. But again, you already know how senseless of an argument that is because now you come up with "Wikipedia's style guide literally says to avoid information-dense tables unless absolutely necessary". ...you are aware that everyone can look that up, right? These tables are direct counterparts to other tables that are very much commonplace in articles about Apple products and their support cadence and other similar products. Yet nobody ever made an issue about this. These tables aren't "information-dense", a "yes/no" matrix is as simple as a table can possibly get. And that argument yet again seems to fly directly in the face of your previous argument that these tables only duplicate the "End of life" column of the "Overview" table. So are you saying that the "Overview" table is also information-dense and thus must be removed, or are you saying that these tables do actually provide information that isn't elsewhere stated in this article, or are you saying that your argument there made no sense from the start?

So, respectfully, restore the page until an actual consensus is reached. There is no consensus for their removal, there are however multiple users who have now asked and argued for this article to keep (not "add", "keep") these tables. YannickFran (talk) 22:01, 4 December 2023 (UTC)

Respectfully I am not going to re-add the templates. They add no useful information. Listing "device support" for every single iOS version is redundant and unnecessary, it does not have anything to do with iOS' version history, but rather the respective device's lifespan in terms of software support, which can be found on the respective device's Wikipedia page. This article was made to be a concise overview of each iOS version and its subversions, not how long each device was supported for, which I believe I've mentioned previously.

And by "information-dense", I meant putting information in a table that simply doesn't need to be a table - tables are useful, no doubt about it, but arguably a table that does nothing other than show a checkmark or an "X" for something is a bit on the useless side. The "Overview" template, as I brought up in conversation months ago, is far more useful in its purpose in that it shows more than just device end-of-life, it also shows current iOS version, release date, etc. That kinda table is okay and I'm all for it. But three separate templates that only shows a device's lifespan, is a bit out-of-scope and unnecessary for this article, which I brought up before. There are no valid reasons for those tables to exist, especially not for the iPod touch which was EOL'd back in 2022. And that table will eventually become difficult to manage, especially as newer iOS versions come out. That's why I said the tables are an eyesore, because they don't really provide anything of value, and yes, they *do* indeed significantly increase the internal inclusion size, because tables use a lot of complex HTML code to render. And each table that is added, causes the page to take longer to render / load.

To get a gist of what I mean, here is the current inclusion size reported by Wikipedia's internal HTML code for the article:

Preprocessor visited node count: 8777/1000000;  Post‐expand include size: 496479/2097152 bytes; Template argument size: 43158/2097152 bytes

Here is the inclusion size with the hardware support templates included:

Preprocessor visited node count: 10726/1000000; Post‐expand include size: 763872/2097152 bytes; Template argument size: 45092/2097152 bytes

That is an additional 300k bytes that has to be loaded by the browser, which means longer loading times, especially for people on slow Internet connections which is incredibly common in less developed countries, for tables that are probably only cared about by very few people, and which contains information that can be found on a respective iOS device's article under its infobox. And once more and more iOS versions and devices come out, the more those HW support tables have to grow both vertically and horizontally, which will become even more of a maintenance burden. I'm honestly just providing my two cents here. The tables respectfully do not add anything of value that is not already covered either in the Overview table, or the individual iOS device articles.

My argument for the version history tables is that they do indeed provide value. A lot of people care about how iOS has evolved, and having the version history tables there mean that a overview of how a given iOS version has made iOS better (or worse depending on who you ask) is always there for people who are curious. And by not having the hardware support tables there, there is more space for proper text content. These reasons (and the others I've mentioned) are precisely why I believe that the hardware support tables do not belong in the article. They do not really provide value that is not already there, and its why I am not going to add them back. - Evelyn Harthbrooke (leave a message · contributions) 01:33, 5 December 2023 (UTC)

And this is exactly what I mean: you just keep repeating the same point over and over again as if you actually have a point. To get - once again - back at the inclusion size: this is not an issue. Once again; at best that merits an article split, not removal. Second, you are now just inventing definitions for what "information dense" means, the fact that something could be formatted as something other then a table doesn't make the table-version of it "information dense" (and yet again, we'll entirely ignore presentation of information I guess) because quiet frankly everything you can format as a table can be formatted as plain text (including the content of version history tables, which actually makes much more sense as text compared to trying to format support evolution, so there's that too if you really want to argue on your "information dense table" definition you bring up here). Third, just because the iPod is EOL doesn't mean we can just go around and scrap all information about it from the article. Fourth, these tables are perfectly manageable (again, stop repeating easily disprovable thing, if you want to see an "unmanageable" table, I suggest you go and take a look at articles like Apple silicon, and people manage those just fine).

Finally, I never argued against having the version history tables, but if space constraints become an issue (and lets yet again be very clear about that: they very much are not right now) and an article split would become necessary, it's those tables would be the ones that would have to be moved to their respective version articles as has been the precedent for many other articles like it. Regardless, here you argue yet again for the need of "more space for proper text content" and I'll repeat yet again: that is not an argument for information removal. Also ignoring that you're basically repeating the claim that information is repeated in tables that do not exist.

But I've already made all those arguments. You've just opted to ignore it and instead repeat yourself as if that makes you're right and then shut down any conversation people are willing to have with "and that's final". Meanwhile, there never was a consensus for their removal in the first place, and as long as there is no consensus for their removal, they should be kept. YannickFran (talk) 08:12, 5 December 2023 (UTC)

You're the only one who's defending them now, the other one who defended this left Wikipedia. I disagree with their creation as a whole. And regarding your Apple Silicon argument, those tables actually have a reason to exist in that they actually have proper information other than checks and X's. Hardware support tables? No. And I'm repeating the reasons I've already mentioned because they are valid reasons, you just refuse to accept them as valid reasons, for reasons I don't entirely understand. I've discussed a multitude of reasons here, you've refused to accept every single one.

And you literally disregarded Wikipedia's entire discussion process just to revert a removal that has ONLY been reinstated by YOU. That is not consensus, its the same person adding the same stuff over and over again. Those templates, again, have no reason to exist. - Evelyn Harthbrooke (leave a message · contributions) 08:28, 5 December 2023 (UTC)

You are repeating arguments that, even if valid, wouldn't require removal, but at best an article split. And by the way: And you literally disregarded Wikipedia's entire discussion process just to discuss a change that has ONLY been reinstated by YOU. That is not consensus, its the same person removing the same stuff over and over again.

You haven't been discussing anything. What you have done is throw about 10 different arguments, some of which contradict each other, at the wall, hope one of them might stick, and completely disregard anything anyone has said. You've been holding a monologue. You've refused to actually argue on any points other than just repeating yourself over and over again. Example given: the "inclusion size" "issue". I'm not arguing it doesn't make the article larger, of course it does, that's what any information does, that's what information is. Disregarding that at this point it very much is not an issue, that still wouldn't warrant removing information, that's what article split requests are for.

On this talk page, there are multiple people that have either argued or asked for these tables to remain. You are the only one arguing for their removal. And frankly, at best it seems you just have some weird personal vendetta against these tables.

And now you're arguing that because people who already voiced their opinion on keeping this information on this page aren't repeating those opinions, we can just disregard their opinion? There was no consensus to remove them the first time around, exemplified by the fact that the person who removed subsequently restored them for the very reason that they agreed that there was no consensus. There was no consensus when you removed them earlier this year with multiple people arguing against you. And here yet again is no consensus to remove them this time around, and again, I'm not the only person arguing for them to remain (so what are you even talking about that it is just me?). You don't get to restart this discussion over and over again every few months until everyone is tired of it and then go "see, nobody wants to keep this". YannickFran (talk) 08:57, 5 December 2023 (UTC)

The problem is, the template went weeks with being gone until you suddenly decided to readd them. That's not cool, its an abuse of the process. - Evelyn Harthbrooke (leave a message · contributions) 09:09, 5 December 2023 (UTC)

Believe it or not, but people don't constantly keep an eye on articles. Regardless, I was not the one initially restoring them. You are the one abusing the process here, these tables are part of this article. Your removal has been disputed by me and others. You're the only one pushing for this. If a change is under dispute, discuss it first and reach a consensus. Adding these tables has never been disputed, its you removing them that has however. YannickFran (talk) 19:26, 5 December 2023 (UTC)

Also, yes, I somehow have a personal vendetta against ones and zeroes on a screen. No, I don't. I just really don't think tables related to "hardware support" belong on an article involving an operating system's version history, and version history alone. Those tables would be better off on some sort of article involving iOS devices instead. - Evelyn Harthbrooke (leave a message · contributions) 09:10, 5 December 2023 (UTC)

Note how, yet again, you aren't actually arguing any points. But you did, yet again, introduce a brand new point: hardware support doesn't belong on an operating system's version history. Which is weird because your earlier argument was to keep repeating that these tables duplicate information on this page from the overview table and version tables. So which one is it? Is it or is it not duplicated information? And if it is, then we should remove that information from those tables as well, shouldn't we, because it doesn't belong here? Regardless, these tables were specifically moved here from hardware lists because people argued this is where they belonged. YannickFran (talk) 19:44, 5 December 2023 (UTC)

Seeing as you continue to refuse to have an actual discussion on any of the counterpoints raised, instead opting to only react to an obvious hyperbolic statement rather than any of the actual arguments, it's very clear that you are just not willing to discuss this in good faith (then again, your "my opinion is final and I don't care what anybody else thinks"-stance made that very clear too). These tables may have been gone for weeks "without anyone noticing it" (note that you're reacting in a discussion created by someone who at the time did notice it), but they've also been here for months without anyone actually raising concern about it but you. When you removed it, that was again immediately followed up by someone asking them to be restored. And of course a couple of people have in this discussion also raised their voice for its restoration or have shown an indifference. Neither of which positions supports removal. You are not the sole arbiter of what goes in this article. So until an actual consensus can be reached, I'll restore that section to the last agreed upon revision, which I'm happy to say, you made. This is also in line with decisions made on other articles to move these tables here because this was the more appropriate article for them in the first place.

There is clearly no point in discussing this with you, every time I point something wrong out in your argument, you don't even acknowledge that counterargument, let alone discuss it and instead just jump to another - sometimes even contradicting - argument ("it duplicates info elsewhere in this article" vs "this info doesn't belong in this article"), a technical aspect that you clearly don't know anything about (accessibility), random Wikipedia policy that doesn't even apply (like the size limit (and even if that was an issue, split at best, not removal), and WP:NOTCATALOG), a weird personal preference that has absolutely no bearing on what content should be on Wikipedia ("eyesore"), or go back around again to an previous argument whilst yet again not acknowledging or addressing any concerns raised against that or any other argument. You're not even willing to acknowledge that there have been other people in this thread who've said they think it should remain, are indifferent to it, and/or agree that there is no consensus to move forward with their removal, because that would mean admitting you're the only one who wants it gone and that's a consensus you don't want, so you just disregard their opinion because "they left". There is no use in discussing anything that way. YannickFran (talk) 16:40, 8 December 2023 (UTC)

Respectfully I am not going to re-add the templates.

Respectfully stop acting as if you own this article. It is not solely up to you. Saying stuff like this while simultaneously accusing @YannickFran of "edit warring" heavily suggests that you believe you have privileged editing rights over this page. You do not. Brusquedandelion (talk) 09:32, 7 December 2023 (UTC)

There was also no consensus to remove the tables, yet you deleted them from the article. Brusquedandelion (talk) 09:39, 7 December 2023 (UTC)

iOS 16.4.1 is not a Rapid Security Response update

iOS 16.4.1 (released on 7 April 2023) contained bug fixes and security updates. It is not a Rapid Security Response (RSR) update as stated in the table and should be corrected.

iOS 16.4.1(a) (released on 1 May 2023), was in fact the first RSR. It is a separate update in its own right, to be distinguished from iOS 16.4.1. 128.106.123.247 (talk) 07:44, 7 June 2023 (UTC)

um it doesn't say its a rapid security response, just that it *received* a rapid security response. - Evelyn Marie (leave a message · contributions) 08:51, 7 June 2023 (UTC)

and no, we are not adding RSRs as separate updates to the table. that is a waste of space. - Evelyn Marie (leave a message · contributions) 08:52, 7 June 2023 (UTC)

[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

[1]

[2]

[3]