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

[Ken Laskey <klaskey@mitre.org>]

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, michael.poulin@uk.fid-intl.com 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