[node-devel] Versioning of oVirt Node

[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.

> 
> Greetings!
> fabian
>