Re: [office] Backwards compatibility?

[Daniel Carrera <daniel.carrera@zmsl.com>]

robert_weir@us.ibm.com wrote:
> Two general types of ways to evolve a schema -- widening the contract or 
> narrowing the contract.  Widening can break backwards compatibility. 
>  Narrowing can break forward compatibility.
[snip]
> 
> I would like to see the TC have a consensus 
> understanding, hopefully codified in a working document, on how it will 
> deal with evolution and versioning.   What are the best practices for 
> ensuring that we don't confuse implementors and users with unexpected 
> incompatible changes?  How do we set the right expectations on when and 
> how such incompatible changes will happen?

One way to at least document the nature of the changes is to say that 
"minor" releases (1.1, 1.2, 1.3) only widen and "major" releases (2.0) 
can narrow. In other words, forward compatibility is guaranteed within 
any series, and backward compatibility is never guaranteed.

We could also come up with a guideline so that backward compatibility is 
only broken in ways that degrade gracefully. For example, we can say 
that any new features will go in a new namespace unless it's a "major" 
release (2.0).

I don't necessarily advocate these guidelines, this is just an idea. 
They only thing I do advocate is that we guarantee forward compatibility 
accross minor releases. I do think that's important.


Best,
Daniel.
-- 
      /\/`) http://opendocumentfellowship.org
     /\/_/
    /\/_/   A life? Sounds great!
    \/_/    Do you know where I could download one?
    /