RE: [wsdm][UPlat] Versioning

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

Yes, Brian, I agree. For MUWS needs (i.e. versioning of the manageability interface and service/edpoint that provides it) defining a targetNamespace that includes version is sufficient. That could be recorded as a solution that we forsee and existing platforms support this approach already and so we don't need to do anything for MUWS in this respect.

However Brian Carrol was working on the versioning of WSs (or possibly versioning of any resource, I suppose). And that is linked to change descriptions, revisions, etc. Those concepts are valuable at the architecture level. I don't think it was a requirement on the platform or anything like that, but rather a way to represent versioning, etc. in the architecture and learn how to deal with it when expressing various manageability capabilities.


-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: MURRAY,BRYAN (HP-Seattle,ex1) [mailto:bryan.murray@hp.com] 
Sent: Thursday, October 30, 2003 2:35 PM
To: 'Andreas Dharmawan'; wsdm@lists.oasis-open.org
Subject: RE: [wsdm][UPlat] Versioning

Do we need to specify the format of the version? In many cases, versions of web services are expressed by changing the namespace of the description of the web service - this is a URI.

Also, we need to clarify what the version applies to.

Are we describing the version of the service - for which there may be many endpoints?
Are we describing the version of an endpoint - for which there may be many interfaces?
Or are we describing the version of an interface?

It seems likely that manageability capabilities may be versioned independently, and that an implementer will want to mix and match manageability capabilities with various versions into one manageability endpoint. This implies that it may be important to discover the specific version of each of the management capabilities or at least the management interfaces. So an endpoint will need to provide a set of versions to describe the set of management capabilities it exposes.

I agree with your requirement for change descriptions. And this is where information about what the previous version is would be, as well as how this version extends/replaces/fixes/etc. the previous version.


-----Original Message-----
From: Andreas Dharmawan [mailto:andreas@westbridgetech.com]
Sent: Wednesday, October 29, 2003 4:08 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm][UPlat] Versioning



Here is my first cut on Versioning:

* Versioning:
  - Definition(s):
    Versions: A sequence of copies of (Functional and Manageability)
    Webservices incorporating new modifications. Each version is 
    identified by a number, following a certain specified format 
    signifying the major version number and the release number.

    Typically an increment in the major version signifies a   
    substantial increase in the function of the Webservice or a
    partial or total re-implementation.

    Whereas the release number increases each time the Webservice 
    is changed in any way and re-released.

    Versioning information must also contain change description
    that describes what has changed in a revision compared to
    the previous one.

  - Management Need(s):
    1. Version numbers are useful so that the manager can know 
       if the manageable Webservice interfaces have changed 
       (bugs have been fixed or new functions added) since she 
       obtained her copy. She could also learn whether a bug 
       report relates to the current version. 
    2. A manager of manageable resources must have the ability to
       query the available endpoints' revisions along with the
       corresponding change descriptions such that the manager
       can discern the most appropriate and compatible interface of
       a particular manageability function that her management 
       client can use.



To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.ph
p.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.