Template talk:Infobox OS

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Software / Computing  (Rated Template-class)
WikiProject icon This template is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
Taskforce icon
This template is supported by WikiProject Computing.

Displaying more than one stable or preview release?[edit]

Sometimes there might be more than one preview release; for example, iOS and OS X have betas of updates to the current stable release and two betas of the next major release, one for developers and one for users (the two betas for iOS 10 have the same build number, but the two betas for macOS Sierra don't).

There might also be multiple stable releases, although that seems less likely.

The only ways I've seen to display that are:

  • put the full release information - version and release date - in the "latest xxx version" parameter, with a <br/> between them to put them on separate lines, and don't use "latest XXX date" at all;
  • use a template for that information, and use multiple {{LPR}} or {{LSR}} templates in the body of that template.

The former means you don't need a possibly-otherwise-unnecessary template for the release information; the latter means you aren't stuffing dates into "latest xxx version", in case some software cares about the metadata and wants the version and date information separate.

Which of those is best, for articles that don't already have version information templates for other reasons? Guy Harris (talk) 02:25, 8 July 2016 (UTC)

Hey. I don't think you should list multiple version numbers. Only the latest version. The connotation of announcing the next major version is far different from announcing the next major patch, and I think it is quite clear that for Wikipedia infoboxes, which are subject in glance, the former is more important. Fleet Command (talk) 07:03, 8 July 2016 (UTC)
OK, you're saying that the only "preview versions" we should list in any infobox are "next major release" preview versions, not "next software update" preview versions? Guy Harris (talk) 18:19, 8 July 2016 (UTC)
And if an OS has separate developer and public beta versions, as macOS and iOS do, should only the most recent of them be shown (even if, as appears to be the case based on build numbers, a developer beta coming out on July 5 is a newer build than a public beta coming out two days later)? Guy Harris (talk) 21:14, 8 July 2016 (UTC)
I never said only. If someone reported something minor, the best thing is to do nothing about it. (Assuming there is nothing else wrong with the whole contribution.) But I think we should report the latest version (as opposed to the most recent one). When you have a dilemma, answer this question: Which of these versions represent the highest point of the OS development? For example, report XXX v21.0 released 20 July 2015 (latest) instead of XXX v20.203 released 20 January 2016 (most recent). FleetCommand (Speak your mind!) 16:59, 9 July 2016 (UTC)
"I never said only." What you said was "Hey. I don't think you should list multiple version numbers. Only the latest version.", so you did, in fact, say "only".
Your comment pretty much amounts to "don't list betas of updates to the current major version". Others who have updated the infoboxes seem to disagree, so I don't see a consensus either way. Guy Harris (talk) 18:55, 9 July 2016 (UTC)
Don't put words in my mouth. Articles about individual versions of an OS, e.g. Windows XP can still list beta service packs. Windows 10 and Windows 10 Mobile notably update the version numbers often.
iOS and OS X are not the only OS articles on Wikipedia. And it seems so self-contradictory that a field reads "latest preview version" and lists a far-from-latest version. FleetCommand (Speak your mind!) 23:04, 10 July 2016 (UTC)
Not listing, in the main article for an OS, preview versions of updates to the current major release seems reasonable. I'd still want to hear others weigh in on this, however.
That still doesn't address OSes that have, for the next major release, two streams of preview updates, a "developer" stream, and a "user" stream, with the first one presumably intended for people testing 1) whether their existing versions of their software works on new releases and 2) whether under-development versions of their software that uses the shiny new features of the new release works correctly, and with the second one intended for people who want to test 1) whether the new version works for them and 2) whether the shiny new features of the new release work for them. The "developer" stream releases may have a newer build as the latest version than the "user" release does - the expectation might be that people wouldn't use the "developer" releases for day-to-day work but that people willing to live on the bleeding edge might use the "user" releases for day-to-day work - and might even have a newer build come out in the "developer" stream before an older build comes out in the "user" stream.
There might be some who would argue that this means the most recent builds on both streams should be shown. Guy Harris (talk) 00:29, 11 July 2016 (UTC)
The situation you are describing reminds me of Windows 10 that has three release rings: Fast, slow, release preview ring. If you want to ask others, then, according to X!, you should probably ask ViperSnake151, Codename Lisa, NeoGeneric, The Professor123 and Comp.arch. Of course, you can look up OS X and iOS stats but you yourself are the top editor there. (Now that I come to think of it, I have only seen you adding multiple version numbers; it was some office software article.) FleetCommand (Speak your mind!) 07:26, 11 July 2016 (UTC)
If by " I have only seen you adding multiple version numbers" you mean that I'm the only person you've seen adding multiple version numbers, rather than that you've never seen me, for example, reducing multiple version numbers to single version numbers, I'm not the only person who's put multiple versions into inboxes in OS X and iOS articles - I'm not even the person who started the tradition; see, for example, this edit, which put in both software-update and next-release betas, and this edit, which adds separate developer-track and user-track (public) betas.
I'd rather just throw something out to the general public, so I'll try putting something in the talk pages for various OS X, iOS, and Windows pages; if that doesn't provoke any response, I'll consider asking the people you mention, as well as IAdam1n and possibly Bbb2007. Guy Harris (talk) 08:00, 11 July 2016 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Good idea. FleetCommand (Speak your mind!) 08:11, 11 July 2016 (UTC)
OK, done. I somewhat arbitrarily chose Talk:OS X, Talk:iOS, Talk:Windows NT, Talk:Ubuntu (operating system), Talk:Red Hat Enterprise Linux, and Talk:Debian for OSes and Talk:macOS Sierra, Talk:iOS 10, and Talk:Windows 10 for OS releases; perhaps other Linux distributions, *BSDs, and commercial UNIXes, and various non-UN*X/non-Windows OSes should be included, along with other Darwin and Windows NT derivatives, and so on. Guy Harris (talk) 08:23, 11 July 2016 (UTC)
Hello, Guy Harris
I saw your messages which you have left everywhere. They say that you are comfortable with whatever outcome. Also, I mulled over your rather aggressive conversation with FC here. The rather contrasting attitudes notwithstanding, please tell me what is the core problem anyway? Is there something you want done and can't?
Best regards,
Codename Lisa (talk) 14:05, 12 July 2016 (UTC)
No, there isn't. All I want is to make sure that all sides are represented in this discussion, and some conclusion reached as to whether this infobox should support showing multiple preview and stable releases. If the conclusion is that it should, it should perhaps be modified in some way to do so more easily; if the conclusion is that it shouldn't, the places where it's showing that should be changed not to do so. Guy Harris (talk) 16:58, 12 July 2016 (UTC)
I am against changing this. Adding different preview versions adds unnecessary detail to the infobox and I do not see why it is not sufficient to mention the most recent version. The iOS 10 infobox is already far too bloated and repeats information that is presented well in the article itself, using lists or tables.–Totie (talk) 15:14, 20 July 2016 (UTC)

Deprecated fields lack a description and emphasis on deprecated status[edit]

I couldn't find a way to change deprecated status value to <strong>, like the way a required value is emphasized. It's also not very appropriate to use the description field of a deprecated field to state the deprecation status again, because that should be reserved for explaining the actual purpose of the feature. There was also a problem with Codename Lisa using uppercase letters to denote deprecation which may break accessibility, but I've fixed this. It would also be nice if the background color of those table rows could be changed for deprecated features, but I have no idea how to do this with templatedata. (talk) 05:09, 7 September 2016 (UTC)

Minor reorder: ARM first?[edit]

Proposal: In Template:Infobox OS/doc, in section "Example", in the brief list of "supported platforms", move "[[ARM architecture|ARM]]" to the start of the list.

Reason: Such a move is long overdue, given how the microprocessor market has grown and evolved. Internationally and nationally, for many years, by unit volume, the sales and growth rates of ARM architecture chips, and devices based thereon, have exceeded those of the Intel architecture. In 2016, the number of ARM chips sold annually reached an estimated 4.1 billion. By unit volume and growth rate, a solid case exists to list ARM first. ARM occurring first or earlier in the order of the "supported platforms" list suggests and encourages a more volume oriented bias, viewpoint, or agenda, of fairly simple, transparent, unarguable Wikipedia:Neutrality; see WP:DUE. ARM being first is also more correct alphabetically, which makes lists cleaner and is aesthetically pleasing, but is of secondary importance to neutrality. This all seems obvious, straightforward, and uncontroversial.

Counter reason 1: In contrast, by financial value, the sales of Intel architecture chips, and maybe devices based thereon, have always exceeded those of the ARM architecture, and will for many more years, but the growth rate is far slower. ARM occurring last or later in the order of the "supported platforms" list suggests and encourages a more commercial, financial, and PC (Windows + Macintosh) oriented bias, viewpoint, or agenda, of greater complexity, opacity, and more debatable neutrality.

Counter reason 2: The example "supported platforms" treats the operating system Debian, which may have more instances running on Intel than on ARM architectures. However, the guidance in Template:Infobox OS applies to infoboxes for all operating systems, not only to one.

Conclusion: In a short list of computer chip architectures, should ARM be first or last? Ideally, Wikipedia should be exemplary in as many ways as possible, and stand well above as many questionable biases as possible.

I know that everyone is busy, and that these sorts of issues can take a long time to resolve. I will thus await response(s) for at least a month or two, which seems a reasonable time for comment. Then, if no objections are posted, I will make the proposed change.

Thank you all for your time in considering this matter. Have a healthy and productive year. -- Jerryobject (talk) 12:57, 26 March 2017 (UTC)

I would not support ordering by some strict measure of popularity. For one thing, there is the "popular by what measure?" problem. (Do we put ARM first simply because a lot more ARM chips are sold than x86 chips? Or shouldn't this be determined by how many ARM, x86, etc., chips are running the OS that's the subject of each particular article in which the template is used?) But ordering alphabetically is a defensible "neutral" choice that would just happen to put ARM near the beginning of the list.
Nevertheless it could be perceived as overly promotional of ARM. If your motive is really to eliminate perceived bias, or influence, then you should be arguing for a random sequence, to be chosen each time the template is used in a new article. Or hey! Maybe the template could pick a random sequence each time it's displayed...
On the other hand, Wikipedia is written for the general reader, and the general reader is far more likely to have heard of x86/x64 than of ARM. Putting a relative unknown like ARM first violates the principle of least astonishment. Hence ordering by familiarity is defensible. (And last is not necessarily a bad place to be. People remember best what they hear first, but they remember almost as well what they hear last.)
But really... what you're suggesting changing here is practically meaningless. It is just an example. The example lists shown here do not dictate ordering in the template's actual use. Nobody will see what's written here unless they happen to look at the template page. I find the notion that the example as constructed promotes any sort of "bias" to be abjectly silly, as silly as my not-serious idea of requiring a random sequence.
Can't you find something more important that needs doing here? And by "here" I mean Wikipedia in general.
If it isn't clear - this is an objection to your proposal. Jeh (talk) 13:49, 26 March 2017 (UTC)
And an objection that I support 100%, especially given that the list is, as you not, just an example - 99 44/100% of people won't even see it. Guy Harris (talk) 17:07, 26 March 2017 (UTC)