In broad terms, strategies for versioning fall into a number of
classes ranging from "none" to "compatible" to "incompatible":
There's no single approach that's always correct. Different
choices or decisions may be appropriate for different applications. But by the same
token, the approaches that are available depend on other decisions or constraints. One very important decision is the whether the language can be evolved by distributed parties such that parallel evolutionary development can occur. The point in the lifecycle of the language may also affect the selection of the versioning strategy for the language. A language commonly goes through a lifecycle of iterative development followed by deployment followed by deployment of new versions. A decision for the development cycle of the language could be different from the decision at the deployment. For example, many W3C languages adopt a strategy of incompatible changes are allowed between Working Drafts and up to Candidate Recommendation, but then Proposed Recommendation and Recommendation are all compatible versions.
The variety of decisions makes it imperative to plan for versioning from the start. If versioning is not planned from the start, then the possible versioning strategies may be constrained by decisions that have been made implicitly rather than explicitly.
Just as there are a number of strategies, there are a number of designs for implementing a strategy. The internet - including MIME, markup languages, and XML languages have successfully used various strategies, either singly or in combination. Summaries of strategies and requirements were produced for earlier technologies [Web Architecture: Extensible Languages] and guided XML Namespaces and Schema.
2.1 Why Have a Strategy?
Different kinds of languages and different versioning strategies expose
different problems. Attempting to deploy a system that
provides no versioning mechanism puts the
burden of version "discovery" on consumers and is often
impractical in anything except a closed system.
At the other end of the spectrum is incompatible versioning approach which
is also problematic. "Incompatible" versioning is a very coarse-grained approach to
versioning. It requires that all of the text must be understood and known by the consumer or the consumer will fault. It often establishes a single version identifier, such as a version number or namespace name, for an entire text.
The semantics of the incompatible approach are that applications decide on the
basis of the version of the text (with or without a version identifier) whether or not they know how to process
that text. If the version isn't recognized, the entire text is
rejected. Typically, when introducing a new version using the
incompatible approach, all of the software that produces or
consumes the texts is updated in a sweeping overhaul in
which the entire system is brought down, the new software deployed and
the system is restarted. This incompatible approach to versioning is
practical only in circumstances where there is a single controlling
authority, and even in that case, it carries with it all manner of
problems. The process can take a considerable amount of time, leaving
the system out of commission for hours if not days. This can result in
significant losses if the system is a key component of a revenue
generating business process and the cost of coordinating the system
overhaul can also be quite costly as well.
The incompatible approach is appropriate when the new version is
radically different from its predecessor. But in many cases, the
changes are incremental and often a consumer could, in practice, cope
with the new version. For example, it might be that there are many
messages that don't use any features of the new version or perhaps it
is appropriate to simply ignore components that are not recognized.
Consider a producer and a consumer exchanging messages of a particular language. Imagine that some future version of the language defines a new component. Because producers and consumers are distributed, it may happen that an old consumer, one unprepared for a new component, encounters a message with a new component sent by a newer producer.
If incompatible versioning is used, old consumers will reject the new
message. However, if the versioning strategy allowed the old
consumer to process the text even with the unrecognized content, it's quite possible
that other components of the system could adapt to the previous
behavior. In effect, the old system would ignore the new component
and so it would "see" a message that
looks just like the old message it is expecting.
For the producer, the result would be that the request is fulfilled,
though perhaps not taking into account the new features. For example, a request that results in a response may return a text of the language without the new component. In many
cases this may be better behavior than receiving an error. In particular, producers using the new language can be written to cope with
the possibility that they will be communicating with older consumers.
If the new system needs to make sure that the new component is understood,
then it can change the language in a way to indicate that the new behavior is not considered optional, aka backwards compatible.
Often, what is needed is some sort of middle ground solution.
2.1.1 Identifying Languages
As part of a strategy for language design, it is often necessary to be able to determine the specific language of a given text. This is often done by providing an identifier of the version of text, such as a version number or some other structure such as an XML Namespace. Regardless of any particular technologies chosen, the language should have an explicit version identification strategy.
Good Practice
Language Identification rule: Any Languages intended for versioning SHOULD have a version identification strategy
The difficult, important, and often overlooked part of a version identification strategy is specifying the meaning and interpretation when a consumer encounters a version identifier it does not know about. A typical problem with version identifiers is that it is unclear what is being identified with the version identifiers. The common misconception is that a version identifier, such as a number, indicates the version of the document. That may be true, but in many cases it is an incomplete and unusable assertion.
In the scenario of documents, there are many possibilities for what a version identifier identifies. For a document that is potentially in many different versions of a language, an identifier that is a number could be:
The highest version of the language the document is compatible with
The lowest version of the language the document is compatible with
The lowest version of the language that has all the features the language uses
The range of versions of the language the document is compatible with
Imagine a name language version 1 is first, last, and extensions; and version 2 is first, last, optional middle, and extensions. If a name contains first and last, should the identifier be version 1 or 2? The previous options yield answers of: 2, 1, 1, 1-2. If a name contains first, last, and middle then the previous options yield answers of: 2, 1, 2, 1-2
Usually, the document contains the version number of the latest version of the language that the producing application understands. Thus the "newest" version of the identifier is used, even if the document itself is valid under older versions of the language. This usually works fine if the producer and consumer are at the same version, or even if the consumer understands the older and the newer version. But forwards compatibility requires that a consumer that doesn't understand the newer version must somehow treat the document as if it was an older version. Approaches for using version identifiers to enable forwards compatibility is covered in 5 Forwards Compatible
As a side note, version identifiers are often used in protocols that exchange documents. One scenario is that the version number identifies the highest version of the language the document is compatible with AND the highest version of the language that can the producer will understand when it is treated as a consumer. In this case it is a protocol version identifier, not just a format identifier. HTTP is a good example. The HTTP specification says "The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication." Because HTTP is a request-response protocol, the capacity for further HTTP communication is the crucial "version" information conveyed. Most documents that might have version #s do not fit that "future capacity" use case, they are just documents that do not have a protocol.. There are cases where a document format is combined with a protocol, such as Atom. These combination protocol/format case are fairly rare and not generally applicable.
2.1.1.1 Version Numbers
Version identification has traditionally been done with a
decimal separating the major versions from the minor versions, i.e. "8.1",
"1.0". Often the definition of a "major" change is that it is incompatible,
and the definition of a "minor" change is that it is forwards- and/or backwards
- compatible. Usually the first broadly available version starts at "1.0". A
compatible version change from 1.0 might be identified as "1.1" and an
incompatible change as "2.0".
The version numbers can be contained in the texts, in the protocol messages containing in the text, or the address for the protocol messages. Some examples are shown below:
<name version="2.0">
<given>Dave</given>
<family>Orchard</family>
</name>
<span class="fn20">Dave Orchard</span>
urn:nameschemev2:given:Dave:family:Orchard
<?XML version="1.1"?>
GET /name/123456789 HTTP/1.1
GET /name/v2/123456789/ HTTP 1.1
It should be noted that associating version number changes with compatibility changes may be idealistic as
there abundant cases where this system does not hold. New major version
identifiers are often aligned with product releases, or incompatible changes
identified as a "minor" change. A good example of an incompatible changed
identified as a minor change is XML 1.1. XML 1.0 processors cannot process all
XML 1.1 documents because XML 1.1 extended XML 1.0 where XML 1.0 does not allow
such extension.
Unfortunately, version numbers often wind up looking very similar to
the incompatible approach. In many approaches, each language is given a version identifier, almost always a
number, that's incremented each time the language changes. Although
it's possible to design a system with version numbers that enables
both backward and forward compatibility - for example XSLT - typically
a version change is treated as if that the new language is not backwards
compatible with the old language.
Some efforts, such as HTTP, try to have the best of both worlds
by allowing for extensibility (in HTTP's case, via headers) as well as
version numbers that explicitly identify when a new version is
backwards compatible with an old version.
One argument in favor of version numbers is that they allow one to
determine what is a 'new version' and what is an 'old version'. But in
practice this is not necessarily true. For example, RSS has 0.9x, 1.x,
and 2.x versions, all being actively developed in parallel. In effect
the version numbers, even though they appear to be ordered, are simply
opaque identifiers. Using version numbers does not guarantee that
version 1+x has any particular relationship to version 1.
Version numbers typically work best when versioning and extending a language is done in a centralized and linear manner. The makeup of each version can then be consistent and well described.
2.1.1.2 XML Namespaces
There are many cases where decentralized and non-linear versioning is desired. The desire for decentralized and non-linear versioning and extensibility was a large motivator for XML and for XML Namespaces. The self-describing and extensible nature of XML markup, and the addition of XML
Namespaces, provides a framework for developing
languages that can evolve in a decentralized manner. XML Namespaces
[ XML Namespaces 1.0] provide a mechanism for associating a
URI with an XML element or attribute name, thus specifying the
language of the name. This also serves to prevent name collisions.