[node-devel] Versioning of oVirt Node

[Fabian Deutsch]

Am Donnerstag, den 03.04.2014, 05:41 -0400 schrieb Alon Bar-Lev:
> 
> ----- Original Message -----
> > From: "Fabian Deutsch" <fabiand at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>, "Douglas Landgraf" <dlandgra at redhat.com>
> > Sent: Thursday, April 3, 2014 12:09:47 PM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > Am Montag, den 31.03.2014, 04:52 -0400 schrieb Alon Bar-Lev:
> > > > Besides that, we could investigate how yum is handling different
> > > dist
> > > > tags on packages in the same repo.
> > > > I.e.:
> > > > node-3.0-0.fc19.rpm
> > > > node-3.0-0.el6.rpm
> > > > In the same repo.
> > > 
> > > no... it should be:
> > > 
> > > node-fc19-3.0-0.fc19.rpm
> > > node-centos-3.0-0.fc19.rpm
> > > node-fc19-3.0-0.el6.rpm
> > > node-centos-3.0-0.el6.rpm
> > 
> > I don't favor such a direction. If the user want's this he could deploy
> > the "alien" isos manually.
> 
> Why alien? I would like fedora engine and the most stable host I can get.
> Or I would like to experiment with the next fedora on separate datacenter.
> Nothing should be alien.
> 
> > 
> > > As there is no reason why I would not like centos hosts for my fedora
> > > engine :)
> > > 
> > > And there is no reason why we should not allow keeping these available
> > > side-by-side.
> > > 
> > > 
> > > > If the el6 variant is installed on the Engine side, does yum
> > > > automatically update to the 3.1 el6 variant when it comes out? Or
> > > does
> > > > yum ignore the different dist-tags?
> > > > 
> > > > > Pre-release:
> > > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm
> > > > 
> > > > Could you please give an example for this.
> > > 
> > > You can see lots of examples at other projects[1]
> > > 
> > > [1] http://resources.ovirt.org/pub/ovirt-snapshot/rpm/fc19/noarch/
> > 
> > Thanks.
> > 
> > > > And - as noted above - I could live with dropping the date for the
> > > > wrapper-rpms - tho it is still handy to have them.
> > > 
> > > Why is it handy, what is it serve?
> > 
> > I was about to say t get have an idea about the build date, and having
> > an incrementing number.
> > But all this can either be achieved by looking at the iso contents or by
> > simple incrementing numbers aka (spec) release numbers.
> > 
> > > > 
> > > > > Released:
> > > > > ovirt-node-iso-3.4.z-1.dist.rpm
> > > > 
> > > > would you replase z in that string above?
> > > 
> > > Each stable release/fix release you issue z is incremented async of
> > > any other package.
> > > 
> > > > 
> > > > > Please note that the downstream component is eliminated in
> > > upstream,
> > > > 
> > > > Could you please exaplain this a bit more.
> > > 
> > > You wrote:
> > > 
> > > > > >
> > > ovirt-node-iso-<ovirt-target-version>-<build-date>.<number>.<dist>.iso
> > > 
> > > This means that you have no upstream version for your own use...
> > > ovirt-target-version is of ovirt, but what is the version of the node?
> > 
> > Oh right. Well the "node" version can be retrieved by looking at the
> > version of the contained ovirt-node pkg. We don't need to expose it in
> > the name.
> > 
> > That's actually what I want to avoid - to expose the node version -
> > because this isn't helpful to th euser - even worse - it is confusing.
> 
> On the contrary... the node version is the part that is important, this is the upstream version of the component, and should not be hidden.

We keep the version for the "real" component which is the ovirt-node
package.
Further more we could say that the ovirt-node-iso component is a
component on it's own with it's own version.
Because the ISO is squashing many packages I don't see a hard reason why
it should have the version of the ovirt-node package.
And my suggestion is to let the ovirt-node-iso component follow the
overall/project version.

For us "No(o)dlers"" it would be interesting to see the ovirt-node
version.
For "vdsmlers" the vdsm version would be interesting.
But to the consumer the oVirt version for which it cna be used is
probably the most interesting - after all it should be a black box ;)

- fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140403/b2955373/attachment.sig>