From d338a63bf82fe193af9de4f5b47e52f20cdd5d8c Mon Sep 17 00:00:00 2001 From: Norman Walsh Date: Wed, 18 Nov 2009 12:53:29 +0000 Subject: [PATCH] Added backwards compatibility section --- docbook/relaxng/docbook/spec/docbook.xml | 57 ++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/docbook/relaxng/docbook/spec/docbook.xml b/docbook/relaxng/docbook/spec/docbook.xml index 3c3579933..2f512b7dd 100644 --- a/docbook/relaxng/docbook/spec/docbook.xml +++ b/docbook/relaxng/docbook/spec/docbook.xml @@ -764,6 +764,63 @@ assertions. processing expectations. A conformant DocBook V5.0 document should respect those constraints and anticipate those processing expectations. + + +
+Backwards compatibility + +The DocBook Technical Committee understands that the community +benefits from the long-term stability of the DocBook family of +schemas. We also understand that DocBook must continue to adapt and +change in order to remain relevant in a changing world. + +All changes, and especially changes that are backwards +incompatible (changes that make a currently valid document no longer +valid under a new version of the schema), have a cost associated with +them. Our duty is to balance those costs against the need to remain +responsive to the community's desire to see DocBook grow to cover the +new use cases that inevitably arise in documentation. + +With that in mind, the DocBook Technical Committee has adopted +the following policy on backwards incompatible changes. This policy +spells out when backwards incompatible changes can occur and how much +notice the TC must provide before adopting a schema that is backwards +incompatible with the current release. + +This policy allows DocBook to continue to change and adapt while +simultaneously guaranteeing that existing users will have sufficient +advance notice to develop reasonable migration plans. + +With respect to schema changes, the following points +must always apply: + + + +A point release (X.1 to X.2, X.2 to X.3, X.1 to X.1.2, etc.) +must not contain any backwards incompatible changes. + + + +A major release (X.1 to Y.0, X.2 to Y.0, X.1.2 to Y.0, etc.) +may contain backwards incompatible changes if +both of the following conditions are true: + + +The change was announced in the release notes for the previous +version (major or minor). + + +The change was announced in a release that occurred at least six +months previously. + + + + + +By these rules, the TC can announce, in V5.1 for example, its +plans to make a backwards incompatible change in V6.0. Then, in V6.0, +if it's been at least six months since V5.1 was released, it can make +that change.
-- 2.40.0