Version in MOF files

Stephen Gallagher sgallagh at redhat.com
Wed Jul 3 12:48:25 UTC 2013


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

On 07/03/2013 02:45 AM, Jan Safranek wrote:
> 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.


Sorry, when I originally commented on this, I was thinking we were
versioning the classes individually, as opposed to the whole of the
provider. If a whole provider is versioned independently, then it
makes sense for the storage and networking provider tarball versions
to match their API versions.

However, it becomes less clear when dealing with the openlmi-providers
package, since it contains multiple agents which should be versioned
independently.

We also need to talk about whole-project versioning as well. For
example, we might want to talk about what shipped in Fedora 19 as
being "OpenLMI 1.0 Beta". Inside that marketing version would be the
specific versions of each tarball that we ship, and inside that, the
API versions provided by the agents. (For another real-world example
that follows this pattern, have a look at nVidia's graphics driver
versioning.)

So we might have the following for Fedora 19:

OpenLMI 1.0 Beta
  |- openlmi-providers 0.0.25
     |- openlmi-account API 0.0.5
     |- openlmi-fan API 0.0.6
     |- openlmi-hardware 0.0.12
  |- openlmi-storage 0.5.1
     |- openlmi-storage API 0.5.1


And so on. Does that make sense?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHUHZkACgkQeiVVYja6o6MEQwCfXjdnuG+wP2EX++4UIjqmKyc9
30AAmwWLOfFfp6SfxOa3vJXfhwnO0tE/
=nyt6
-----END PGP SIGNATURE-----


More information about the openlmi-devel mailing list