Version in MOF files

Stephen Gallagher sgallagh at redhat.com
Mon Jul 1 15:26:49 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/01/2013 11:23 AM, Russell Doty wrote:
> On Mon, 2013-07-01 at 11:17 -0400, 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.
>> 
>> Please see my responses in this thread for an understanding of
>> how an API versioning should work.
> How do we deal with OpenLMI Version 1, OpenLMI Version 2, OpenLMI 
> Version 3, etc.?
>> 

You're still missing the point. OpenLMI Version 1, 2, 3, etc. are
*marketing* terms. We can declare any subset of the functionality at
any time to suddenly be OpenLMI version 2, but that has nothing to do
with the API versions.

For example, let's say that we manage to get the services provider
*perfect* in OpenLMI version 1. We don't need to make any changes to
it at all in order to release OpenLMI version 2, but we *do* have to
make changes to the storage, networking, software providers, etc.

It is far more useful to a consuming client to know which parts of the
API are going to require changes, rather than forcing a version bump
on unmodified code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHRn7kACgkQeiVVYja6o6OMzwCcCAi2jsOjnAe4Rp8oUDmJBSN0
OYwAoJ6zlI8vRXlrDgYiWFOD5LTwNlOy
=FoS2
-----END PGP SIGNATURE-----


More information about the openlmi-devel mailing list