Version in MOF files

Jan Safranek jsafrane at redhat.com
Wed Jul 3 06:45:42 UTC 2013


On 07/01/2013 05:17 PM, Stephen Gallagher wrote:
> On 07/01/2013 11:13 AM, Russell Doty wrote:
>> On Mon, 2013-07-01 at 17:03 +0200, Jan Safranek wrote:
>>> On 07/01/2013 04:36 PM, Russell Doty wrote:
>>>> Do we want to key the MOF files to a RHEL specific X.Y.Z
>>>> versioning, or have an OpenLMI version for the MOF files? If
>>>> the latter, do we want to version on a Provider by Provider
>>>> basis, or have a single version for OpenLMI?
>>>
>>> Various OpenLMI providers have different releases, e.g.
>>> -Providers was released several times while Storage was released
>>> only once in past months. I'd like to have the API versions
>>> separate.
>> How about having a single X version across all of OpenLMI, and let
>> Y and Z vary by Provider?
> 
> I think you're conflating version types.
> 
> What Jan is talking about here is a *functional* version that
> identifies the version of the API that is being served.
> 
> You're talking more about a *marketing* version which is for
> appearances only. This is better directed at the tarball/package
> versioning and not the API.

Well, I was initially thinking about having the API version and the
tarball version the same.

Can it happen that we introduce major change internally and keep the API
version the same? I can only think of major rewrite of a provider, e.g.
from Python to C with the same CIM API, how likely is this to happen?
IMHO bumping also API version might be good idea in this case, various
corner cases and error cases might behave differently.

Jan


More information about the openlmi-devel mailing list