Update entry for 'backward compatibility'

[daobrien]

Some time back the WN group agreed that the existing guidance of avoiding 'backward compatibility' is outdated, and industry standards, RHT discussions (and some common sense) supports that.

That said, it is not a phrase to be used lightly. From the CSG:

Discuss backward compatibility with caution, as claims may promise future actions that are legally binding. Don't use "backwards compatibility." Example: "This solution will be backward compatible with at least 3 previous releases."

The current RHSG entry still says to avoid this phrase and to use 'compatible with earlier versions'. We need to update the entry to reflect the CSG.

[julian-cable]

I am unsure what to do about this entry.

The current RHSG entry for "backwards-compatible" gives similar guidance to the IBM Style entry for "backward compatible" (though with a slight difference between the entry titles).

The Corporate Style Guide now has guidance that diverges from the above. Given that the CSG is more marketing-oriented, I'm not sure that we should align closer to the CSG than to IBM.

In the CSG wording, it is unclear to me whether the example provided is a good or a bad example. Also, their entry does not suggest what wording might be used instead.

Although I'm not certain, I think that one of the reasons why IBM avoided "backward compatible" might be to avoid any negative connotation of "backward", in a similar way to using "an earlier version" in preference to "an old(er) version".

[daobrien]

Thanks for the feedback.

While the CSG and the RHSG diverge in certain areas to accommodate specific contexts, they intentionally remain aligned where doing so best serves our goals. This is one of those instances.

As noted in the original post, the WN group previously agreed that avoiding the term "backward compatibility" is outdated. Current industry standards, internal RHT discussions, and practical usage all support adopting this term here. It's not about being marketing orientated or otherwise, but rather what do people search for and use.

I see what you're saying about adherence to the base guides, but our primary goal here is clarity for the technical reader. Given that "backward compatibility" is standard across peer industry docs (Microsoft, Google) and matches user search queries, overriding the base rule here offers the best reader experience.

In terms of search discoverability, keyword volume data from SEO platforms (Ahrefs, Semrush, and Google Trends) shows that 'backward compatibility' is the primary technical term users search for. Exact match search queries for 'backward compatibility' outpace descriptive, passive phrasing like 'compatibility with earlier versions' by roughly 10x to 20x in global search volume. Sticking with the standard term ensures our content surfaces effectively in search engines and AI RAG tools.

[julian-cable]

@rclee33 @sffrench What are your thoughts here?

[sffrench]

Clarity for the reader and discoverability would override a strict rule for me.