RE: [soa-rm-ra] quick thought on versioning and description

I totally agree with "defining a versioning scheme from having a standard way to 
indicate the version scheme being used". This means, we, probably, have 
to point onto the version scheme mapper element of SOA infrastructure w/o 
further details.

 

The original issue of this discussion thread - how to 
collect information about service changes that have not been reflected in the 
service version changes - is not that simple. In particular, if we consider just 
historical interest in the changes, we can collect the information in a 
repository. However, if the change might eventually end up with "someone using the service finds 
something isn't working just right" and we have not changed the version, 
it becomes an ambiguous case. Therefore, any change must reflect in the 
version number.Ken's idea about additional section in the version is good 
especially if we can add a version meta-model definition about 
mandatory/optional status of each section of the version number. 

 

For example, we have a version value of 10.4.8.217  and the last 
position (of value 217), reflecting minor change which does not affect 
functionality (as the provider suggests), is optional. It will not affect 
consumer's code if we use rule-based version compatibility control model but we 
can demonstrate that  the change was recognized and managed properly from 
the service provider side.

 

- Michael

  

  
  From: Ken Laskey [mailto:] 
  
Sent: 11 March 2007 18:43
To: 
  
Cc: 
  
Subject: Re: [soa-rm-ra] quick 
  thought on versioning and description

  

OK, replying to everything that been said to this point.
  

  
What I'm looking for is a consistent way to capture changes that we agree 
  do not affect the version number.  However, if someone using the service 
  finds something isn't working just right, they can look back to the log for 
  clues as to what may be causing the supposed glitch.
  

  
My first idea was to extend Michael's idea by adding another version 
  field that indicates changes in the log.  Supposedly, a log entry will 
  not affect use or interoperability but provides a way for interested parties 
  to know something changed.  So two version numbers may look like 
  10.4.8.217 and 10.4.8.220.  The important thing is the 10.4.8 (or maybe 
  just the 10.4) and the fourth number (which I expect to iterate more often 
  than the others) would usually be irrelevant.
  

  
Now, I also want, to the greatest extent possible, to maintain opacity, 
  and I appreciate I'll never be able nor would I want to catch 
  "everything".

  

  
A final note on the rathole:  I want to separate defining a 
  versioning scheme from having a standard way to indicate the version scheme 
  being used.  Following the pattern I roughly lay out under Service 
  Description, the value object includes both the value and an explicit 
  indication of its semantics. Thus, we can battle for all eternity on what is 
  the perfect versioning scheme, but in the meantime we can use whatever we have 
  on hand, and we can develop mappings between the ones most commonly 
used.

  

  
We still need to give this more thought.

  

  
Ken

  

  
On Mar 11, 2007, at 12:33 PM,  
  wrote:

  
    
I am with you, Duane; I do not want to get down 
    into bottomless whole (like Alice in the Wonderworld). Let's assume we deal 
    with the version per se; how new version differs from new object - is out of 
    the scope.

    

    
Subscription to the version change event is a good 
    mechanism, I agree. However, when a notification is obtained, the decision 
    has to be made - to call the service in new version or don't. In the 
    rule-based version control, I address this exact moment - the decision 
    making. Nothing more. If new version requires the consumer code change to 
    match new version value, the rule-based version control allows running w/o 
    such change (becuase the version value has to be inside of a range of 
    values). If  version change 
    gets unacceptable for the consumer (i.e. new version value ought to be 
    denied by existing rule), we have two choices: either change the consumer 
    code to meet new service version or review and adjust the rule w/o code 
    change (if new version is still acceptable for the consumer but its rule was 
    not previously formulated to accept such version value change).

    

    
- Michael

  

  
------------------------------------------------------------------------------------------

  
Ken Laskey

  
MITRE Corporation, M/S H305   
    phone:  703-983-7934

  
7515 Colshire Drive          
                fax:      
    703-983-1379

  
McLean VA 22102-7508