[ewg] Re: RFC OFED-1.3 installation

[Doug Ledford]

On Tue, 2007-07-17 at 19:45 +0300, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <dledford at redhat.com>:
> > Subject: Re: RFC OFED-1.3 installation
> > 
> > On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
> > > > Quoting Doug Ledford <dledford at redhat.com>:
> > > > Subject: Re: RFC OFED-1.3 installation
> > > > 
> > > > On Tue, 2007-07-17 at 18:25 +0300, Michael S. Tsirkin wrote:
> > > > > > Let me give an example.  In OFED 1.0, you shipped dapl version 1.2.  In
> > > > > > OFED 1.1, you also shipped dapl version 1.2.  However, code inspection
> > > > > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a
> > > > > > lot, but anything is enough).  So, between OFED 1.0 and OFED 1.1, you
> > > > > > have two different versions of dapl, but with exactly the same version
> > > > > > number.  A person can't tell them apart.
> > > > > 
> > > > > Yes, this sure looks like a problem. I think that versioning needs to be addressed
> > > > > at the package level, not at OFED level though. Right?
> > > > 
> > > > Versioning needs to be addressed at both levels.  You need versions of
> > > > software to start with, but then you still need releases of packages to
> > > > differentiate between different builds of a specific version of
> > > > software.
> > > 
> > > Why would we want to have different builds of a specific version of software
> > > for a specific OS?  Could you give an example pls?
> > 
> > It's how you integrate needed patches immediately while waiting on the
> > next release of the software.
> 
> OK.
> 
> > ...
> > You also bump the release number of the package any time you make
> > changes to the spec file and rebuild.
> 
> Since we have spec files as part of package, this will be really
> the same as the previous case, right?

Depends.  Right now the spec file gets its version out of the configure
stuff.  That version only updates when you update the version of the
software itself.  It doesn't increment on each change to the source
repo, only on the major updates when you would release a new tarball
anyway.  Package versioning is, by necessity, finer grained than source
repo versioning.  You don't release a new dapl tarball just because you
updated some comments to remove a typo.  But you *do* update rpm
versions on every single change, at least if you are going to distribute
the rpm.

Look, rpms are just like versioned tarballs.  Once they go out in the
wild, that particular name-version-release combination is FROZEN.  It
NEVER changes.  Changing the code underlying that particular
name-version-release is just as bad as the whole Linus scenario I
described.  We couldn't stay in business if we let that happen, period.
That's why we have the guidelines that we do for package versioning.

If you need daily builds, there is a way to make that happen that
preserves the upgrade process and preserves unique name-version-release
combinations.  In that case, you would use the daily feature of that
script I wrote.  It spits out a tarball named package-git.tar.gz.  The
-git nomenclature clearly identifies that this is *not* a versioned
tarball and it is *not* required to stay the same.  You could put a date
or head tag on the name as well if you want to make it unique.  I didn't
do that because then the daily git tarballs take up *way* too much space
in our SCM repo.  Then, you name the package

name-version-0.release.git${DATE}

This way, each daily build has a unique name.  You increment the release
number with each daily build, and the date tag allows you to see at a
glance what date of pull the release goes with.  Once the software has
reached maturity, you simply pull the final name-version.tar.gz tarball
and update the spec to be name-version-1 and it automatically compares
as newer than the daily builds and upgrades.  Then subsequent rpm builds
from that official release version start incrementing the release number
like normal.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20070717/2c489d8a/attachment.sig>