Am Donnerstag, den 03.04.2014, 05:41 -0400 schrieb Alon Bar-Lev: > > ----- Original Message ----- > > From: "Fabian Deutsch" <[email protected]> > > To: "Alon Bar-Lev" <[email protected]> > > Cc: [email protected], "node-devel" <[email protected]>, "Douglas Landgraf" > > <[email protected]> > > 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ node-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/node-devel
