Re: Usage Scenarios for Versioning and Extensibility

[Paul Hoffman / IMC <phoffman@xxxxxxx>]

At 5:14 PM -0700 7/12/04, Mark Nottingham wrote:
> 0) Let's imagine that Atom 1.0 has been released and finalised in 
> all of its glory.
>
> 1) And it was good... except for that nasty atom:title element; 
> after wide deployment experience, it's agreed we need a new version 
> of it. So, a new version of Atom is introduced. The new one isn't 
> backwards-compatible with the old one.
>
> 2) Then, we decide we want to add a new metadata element, let's call 
> it "fog." So, a new version of Atom is introduced.
>
> 3) After a while, someone comes up with a souped-up version of 
> atom:title that is backwards-compatible, just *better*. It gets 
> really popular, and yet another version of Atom is born.
>
> 4) At the same time, a group of rogue Open Source Software 
> programmers descends upon this idyllic scene and introduces its own 
> extensions. Up until now, all of our extensions have been approved 
> and incorporated by the WG, but these are destined to remain 
> separate.
>
> 5) Finally, in 2010, we realise that the Atom feed and entry 
> containers aren't really doing the job, and we need to change their 
> model. Yet Another Version of Atom (YAVA) comes into being.
>
> Any proposal for versioning should address at least these 
> situations, show how the various extensions and changes are 
> identified and disambiguated, and should explain how software is to 
> handle them. They should also consider how combinations of these 
> scenarios are handled.

+1 or more. This is an excellent mix and not at all far-fetched. It 
should help us focus on what we need for versioning and extensibility.

--Paul Hoffman, Director
--Internet Mail Consortium