> Quoting Doug Ledford <[EMAIL PROTECTED]>: > Subject: Re: RFC OFED-1.3 installation > > 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 really looks like this is a work around for when you want to apply a patch without going through maintainer. The way OFED release process works, we really don't do releases all that often, and when we do, we can coordinate with the maintainer. -- MST _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
