1.1 vs. 2.0 planning

[Michael Freedman <Michael.Freedman@oracle.com>]

Title:

I thought it might be useful to begin discussing whether/how to differentiate
what goes into 1.1 vs. 2.0 ahead of our May to F2F.  To get the discussion
started I will reiterate my view which I outlined during our January F2F:
      Version 1.1 should contain only those enhancements that don't add or
alter the 1.0 API.  The exception to this rule would be an addition/alteration
to fix a bug in the 1.0 specification.  The version following 1.1 [Currently
called 2.0] becomes the first update where we change/alter the API.  

At the moment this would mean the focus of 1.1 would not be to added/extend
existing function.  Rather 1.1 would:

• clarify the 1.0 specification where deemed necessary
• define UDDI support [and any other registry we cared about]
• define carrying markup over Soap with attachements/DIME.  
• clarify interoperability and conformance

I think we should limit 1.1 by not altering the protocol/adding new function
for the following reasons:

• 1.1 should follow 1.0 reasonably quickly [Oct-Dec?].  Upgrading API/function so quickly after releasing 1.0 will likely confuse the market and slow adoption.  I.e. 1.0 consumers and producers are likely just coming to market during this time period.
• Our next API/functional release should include changes/function based on real world/customer feedback not just our own ideas/experience.  Our likely 1.1 schedule precludes giving consumer/producers enough time to experience WSRP and communicate true priorities for change.
• Interoperability/Conformance is grunt work compared to defining new function.  If both are a focus of a release  interoperability/conformance is likely to suffer.

     -Mike-