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