Add a statement to docs regarding backwards compatibility

[danielbachhuber]

For those working on Gutenberg's adoption in the broader WordPress ecosystem, it would be helpful to add a statement to the docs regarding backwards compatibility.

Specifically:

• Where does Gutenberg try to maintain backwards compatibility?
• What's the decision-making process around maintaining backwards compatibility vs. not?
• Where has backwards compatibility deliberately been broken?

Once we have this statement in place, it'll be more straightforward to address the existing backwards compat issues.

Related #4151 #4186 #4190

[bobbingwide]

Note that the backwards compatibility label may not be have been applied to all issues which are affected. Some are just labelled bug.

[danielbachhuber]

Note that the backwards compatibility label may not be have been applied to all issues which are affected. Some are just labelled bug.

Correct. I've been adding them as I've come across them.

[bobbingwide]

Can you add #4456 please.

[ghost]

There is also #3964 still unanswered.

[danielbachhuber]

I attempted to answer the backwards compatibility question to the best of my knowledge: https://danielbachhuber.com/2018/10/13/three-flavors-of-gutenberg-backwards-compatibility/

[chrisvanpatten]

Per today's documentation bug scrub, the ticket raises three particular questions:

Where does Gutenberg try to maintain backwards compatibility?
What's the decision-making process around maintaining backwards compatibility vs. not?
Where has backwards compatibility deliberately been broken?

I feel like the first and third questions are best answered in #4186, but the 2nd question is unanswered.

Do any of the leads have particular opinions on that second question (how back-compat breaks are decided)? Is it a question even worth answering in documentation? If not, I'd propose we close this ticket and roll the rest into #4186.

cc @mtias @youknowriad @karmatosed etc.