Version in MOF files

Russell Doty rdoty at redhat.com
Wed Jul 3 13:57:46 UTC 2013


On Wed, 2013-07-03 at 08:48 -0400, Stephen Gallagher wrote:
> 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
Since "marketing" tends to be a pejorative term, can we refer to this as
the Product Version?
> 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?
> _______________________________________________
> openlmi-devel mailing list
> openlmi-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel




More information about the openlmi-devel mailing list