Talk:Forward compatibility

What about the Leapster

I'm no expert, but I think that the Leapster was a portable system that was forwards compatible.

Upward is Backward, Downward is Forward

After conducting some research into the matter, it appears that Upward Compatibility actually means Backward Compatibility. Refer to the following Sun documents for examples of this usage.

http://java.sun.com/javase/compatibility_j2se1.4.1.html

Here is an excerpt.

"The Java 2 SDK, v1.4.1 is upwards binary-compatible with Java 2 SDK, v1.4.0 except for the incompatibilities listed below. This means that, except for the noted incompatibilities, class files built with version 1.4.0 compilers will run correctly in the Java 2 SDK, v1.4.1."

Sun's documents always refer to the earlier versions as the "upward" versions; hence, in the sense of compatibility, "upward" is "backward".

Suggest changing the redirects appropriately.

Google says otherwise.... upward = forward and downward = backward

Plug _"backward compatible" "downward compatible"_ into Google and you will see what I mean.

Also, I didn't check the other languages, but the Japanese entry for backward is "kai" which corresponds to downward. Likewise, the Japanese entry for forward is "joi" which corresponds to upward.

Either way, this needs to be clarified and unified across languages.

Kylethewright (talk) 18:39, 14 December 2007 (UTC)

Why does it need to be unified? If Japanese happens to use the word for "downward" in that language, there's no requirement for English to do the same, or vice versa. Marnanel (talk) 16:35, 21 February 2008 (UTC)

general updates to article

I am removing the part about ms office as it is not really correct. The docx format is a compressed version of a variant of xml describing the document, whilst the old doc format was a proprietary binary format uncompressed. Also the docx patch for 2003 isn't forward compatibility because it was made after the release of office 2007. The code example section is also a bit too technical so I tagged that as well. Da rulz07 (talk) 13:13, 13 February 2008 (UTC)

S-VHS and VHS

A standard VHS VCR can’t just “ignore” the high-resolution S-VHS signal, unless it supports S-VHS Quasi Playback. Otherwise, the effect will be similar to poor tracking. rdl381 (talk) 21:04, 17 April 2010 (UTC)

Later S-VHS VCRs can record and playback full S-VHS quality video onto higher quality standard VHS tapes, though commonly with a warning that the tapes may not play on any VCR other than the one they were recorded on. Some Digital 8 camcorders could record onto Hi-8 tapes with the same caveat of possibly not being able to playback on any other Digital 8 camcorder or deck. So does that make the VHS and Hi-8 tapes forward compatible media or are the decks and camcorders backward compatible with the media originally intended only for analog or in the case of VHS for lower quality analog video? Audio for VHS maintained forward compatibility, first with stereo then Hi-Fi stereo - any non-Super VHS tape will work in any VHS deck and as noted above even S-VHS tapes will play in the cheapest deck that has SQPB, which is just about all of them made since circa 1995. Bizzybody (talk) 09:21, 17 May 2011 (UTC)

So does that make the VHS and Hi-8 tapes forward compatible media or are the decks and camcorders backward compatible with the media originally intended only for analog or in the case of VHS for lower quality analog video? It makes the *media* forward-compatible but not the decks. Indeed you can have the situation where a VHS tape will not play in a VHS deck, because the tape contains an S-VHS ET recording. In one sense, S-VHS ET is in fact a separate third standard, to which S-VHS decks are not forward compatible either. It just uses cheaper tape stock to achieve something better than VHS but not as good as S-VHS. You cannot, for instance, record in LP mode on a standard VHS tape with an S-VHS ET deck; but if you provide the same deck with an S-VHS tape, you can record in LP mode because it will use S-VHS proper, not S-VHS ET. Whophd (talk) 05:02, 4 November 2011 (UTC)

Forward compatibility in gaming systems

Wii can play Wii games as well as outdated Gamecube games, Playstation 3 can play Playstation 2 games, and the Playstation 2 could play a Playstation (classic) game. The Xbox 360 is also compatible with previous Xbox titles. Please change the gaming section, as the uncited knowledge is false. Thank you, --208.120.116.80 (talk) 17:34, 1 July 2011 (UTC)

Again: Upward Compatible Means Backward Compatible in the OpenGL Spec

According to the OpenGL ES 2 full spec, Appendix D "OpenGL ES 2.0 is not upward compatible with prior versions (OpenGL ES 1.0 and 1.1)." No matter what "Google says", People who write specifications seem to be clear on that topic. 217.229.52.176 (talk) 17:01, 25 October 2011 (UTC)

RFCoC (Request For Comments on Changes) for Forward/Backward terminology

I've changed the main article for new "Forward / Upward / Future-Time / Newer-Version compatibility", by adding better "Future-Time / Newer-Version" terms that show exactly the true meaning of 'forward' or 'upward' (the latter that challenged by many for reversed order on other materials).

I think it should be clearly defined like my additional terms, since the whole explanation is about timeline (past-future) and/or versioning (older-newer), you can recheck it again in the article for the whole idea meaning of the term.

E.g: "Future/Newer(-Version) compatible" is directly-understandable, perceived distinctly better and clearer than "Forward/Upward compatible".

--[Ois1974 @ 2014-03-31 Mon]--

Pokemon is not forward compatible

The Pokemon games do not accept input from the other games - forward compatability would mean that a Gen 3 game could accept a Charmander from Gen 4. Pokemon is backward compatability with X/Y being able to accept input from Ruby/Sapphire.The onl forward compatible games are the Gen 1 games, being able to accept input from the Gen 2 games.--69.159.39.42 (talk) 21:39, 30 June 2014 (UTC)

Forward compatibility of television signals

For black-and-white television broadcast formats to be forward compatible, it would be necessary for them to have been designed in anticipation of possible future changes to television technology (namely, the introduction of colour). Did considerations of forward compatibility play any part in the design of pre-colour television signals, or were the later NTSC and PAL formats designed to be backward-compatible with earlier television sets? — Preceding unsigned comment added by 222.153.170.74 (talk) 12:08, 30 November 2019 (UTC)

There is no requirement that "forward compatibility" be a requirement, or even a consideration, in the design of the older product (although forward-thinking designers are free to do so if they have a long-term plan). Generally, when forward compatibility is required for market reasons, the onus is on the new standard's designers to make that work. Thus, B/W television and mono FM were entrenched when color and stereo were introduced, so both had to be designed to be both forward and backward compatible: new color TV's/stereo receivers can play old transmissions and old sets can play new transmissions, but in both cases, only in BW/mono. In the case of TV's, there wasn't really enough bandwidth for proper encoding of the color components of the signal, due to the existing spacing of the TV channel frequencies. Instead, they had to squeeze in the new components and rely on the fact that the human eye/brain doesn't get as much information from color as it does from overall luminance. If they were thinking of forward compatibility at the start, they would've spread the channels further apart. KevinBTheobald (talk) 18:08, 16 May 2020 (UTC)

Future proof relationship

I believe this article should be understood as a WP:SPINOFF of Future proof specific to computers and communication protocols. Accordingly, both articles could use editing to adhere to good summary style. Daask (talk) 19:29, 9 September 2018 (UTC)

Proposed additions: W3C TAG definitions, design principles, Postel's Law connection

This article has good examples but could use stronger conceptual grounding. I'd like to propose some additions drawing on published W3C and IETF material that the article currently doesn't reference. This would also help address a few threads that have come up on this Talk page over the years.

What I'd like to add: 1. W3C TAG definition in the lead — The W3C Technical Architecture Group's Extending and Versioning Languages series provides a more precise definition: "a change in the definition of a language is forward compatible if consumers of the original language can correctly process text written for the evolved version of the language." This helps ground the concept in published standards work and gives the lead more substance.

2. Design principles section — The W3C TAG documented specific strategies that enable forward compatibility: the "must ignore unknowns" rule, the "must accept and discard unknowns" rule, and the "must accept and preserve unknowns" rule (source). These show how forward compatibility is achieved in practice, not just what it is. The existing HTML section could be strengthened with this context — HTML was forward-compatible because it was designed to accept unknown markup, which is what allowed tags like <img> to be added without breaking existing browsers.

3. Connection to Postel's Law — Forward-compatible design is closely related to the robustness principle from RFC 761 (1980): "be conservative in what you do, be liberal in what you accept from others." The "liberal in what you accept" half describes the core stance of forward-compatible systems. The article on the Robustness principle already exists but isn't linked from here.

4. Definitional challenges note — W3C TAG member Dan Connolly described formally defining forward compatibility as "still an open research problem" in 2007. This is notable — the concept is widely used but has resisted clean formalization, in part because it describes a relationship to future versions that don't yet exist. I think the article is more honest and more interesting if it acknowledges this.

A few notes on how this connects to earlier discussions on this page:

- The recurring confusion about whether "upward" means "forward" or "backward" (discussed in several threads above) may reflect the deeper definitional challenge that the W3C material addresses directly.

- Daask's 2018 observation that this article could be better understood in relation to "Future proofing" is relevant — clearer definitions here would help distinguish the two concepts.

- KevinBTheobald's point that forward compatibility doesn't require the original designers to have anticipated future use is a nuance that the W3C material supports — forward compatibility is about how a system handles what it doesn't recognize, not whether the designers foresaw specific future changes.

All sources are published W3C specifications, RFCs, or archived W3C mailing lists. Happy to share draft wikitext for the actual article edits. Disentropic (talk) 23:50, 11 April 2026 (UTC)

Broader framing in the lead — forward compatibility as a design stance

Now that the W3C TAG and Postel material is in the article (per the previous proposal, which I've implemented), I think it surfaces a mismatch for us to discuss. The lead currently frames forward compatibility as a property a system has as in "a design characteristic that allows a system to accept input intended for a later version of itself." But the sources the article now cites describe it differently: as a design stance that a language, protocol, or format takes toward inputs it doesn't recognize. These are not quite the same claim, and the narrower framing is what the lead commits to.

The TAG's definition is "consumers of the original language can correctly process text written for the evolved version of the language". This applies to any consumer/producer pair, many systems and their own later versions. That broadening matters for two reasons: first, forward compatibility becomes framed as something one can deliberately design into a new system, not merely an accidental property an old system turns out to have. Second, several of the article's own examples only make sense under the broader framing: HTML, the HTTP header-handling rule (now in the Design principles section), and the Postel reference all describe a stance toward unrecognized input rather than a relationship between successive versions of the same product.

The narrower framing also affects who finds this article useful. The current lead reads as primarily about hardware and consumer electronics, which suits the Telecommunication standards and Video gaming sections fine but doesn't match what the new Design principles section describes. Editors working on API design, schema versioning, or protocol specs are a natural audience for the cited TAG material and aren't likely to land here from the current lead.

A broader framing would also take some heat out of the recurring "upward vs forward" question that's come up on this page; the current lead treats "forward" as a temporal direction, which is the part that keeps generating the disagreement. KevinBTheobald's point in the 2020 television-signals thread (that forward compatibility doesn't require the original designers to have anticipated specific future uses) fits naturally under a design-stance framing but sits awkwardly against the current lead. Wanted to float this before drafting wording. Disentropic (talk) 04:15, 19 April 2026 (UTC)