On Tue, 2007-07-17 at 19:45 +0300, Michael S. Tsirkin wrote: > > Quoting Doug Ledford <[EMAIL PROTECTED]>: > > Subject: Re: RFC OFED-1.3 installation > > > > On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote: > > > > Quoting Doug Ledford <[EMAIL PROTECTED]>: > > > > 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 <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg