[ofw] [PATCH] Bump up CI and AL interface version numbers

[Tzachi Dar]

One thing that we can do is have the version composed from a major
version and a minor version.
The major version will change with every official release while the
minor will change every time there is an interface change.

Also see bellow.

Thanks
Tzachi 

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
> Sent: Tuesday, August 26, 2008 3:04 AM
> To: Hefty, Sean; Tzachi Dar; ofw at lists.openfabrics.org
> Subject: RE: [ofw] [PATCH] Bump up CI and AL interface version numbers
> 
> You're confusing release numbers with interface versions.  If 
> you change an interface, you should change the number - it's 
> not the same interface.  Whether the interface version is 1 
> or 1000 is irrelevant to the end user, but not to the 
> developer.  It doesn't matter if the release number changes 
> or not, the interface changed.  There's no reason to 
> artificially keep the numbers low - it's much more valuable 
> to allow upgrades of drivers without requiring rebuilding the 
> system form the ground up.
> 
> I wasn't trying to mix drivers, I was trying to update all my 
> drivers to the same version.  I did a clean build, re-signed 
> all the drivers, and went to update them.
> 
> How do you suggest developers update drivers during the 
> development cycle when working with a cluster of 100+ nodes?

Very simple, copy all binaries from your build machine to the
system32\drivers and reboot the cluster.

Thanks
Tzachi

 
> > -----Original Message-----
> > From: ofw-bounces at lists.openfabrics.org [mailto:ofw- 
> > bounces at lists.openfabrics.org] On Behalf Of Hefty, Sean
> > Sent: Monday, August 25, 2008 4:57 PM
> > To: Fab Tillier; Tzachi Dar; ofw at lists.openfabrics.org
> > Subject: RE: [ofw] [PATCH] Bump up CI and AL interface 
> version numbers
> >
> > >Wrong - the versions should change any time the interface changes 
> > >(not
> > if
> > >there's new functionality added, but if there's a change to an
> > existing
> > >interface.)  If you build something from the tree and try 
> to update 
> > >an
> > existing
> > >install you can end up with systems in a perpetual 
> crash/reboot cycle
> > if the
> > >interface changed but the version didn't.  Move pointers 
> around (like
> > swapping
> > >the p_next and wr_id in the ib_send_wr_t structure) and 
> you'll get a
> > crash if
> > >both the client and provider of the interface don't agree 
> on what the
> > interface
> > >looks like.
> >
> > You set the version number at the end of the development cycle, 
> > immediately before the release, rather than continually 
> bumping it up 
> > with every check-in.  Our next release is 2.0, not 13.0 or 
> 1505 - the 
> > WinOF version is only changing once for this release.  The same 
> > principles apply whether you're talking about a software package, a 
> > single library, or a driver.
> >
> > The problem you had is that you tried to pull part of a development 
> > tree and have it work with a different part of the tree.  An SVN 
> > check- in is not a release, and doesn't have a version number 
> > associated with it.
> >
> > - Sean
> > _______________________________________________
> > ofw mailing list
> > ofw at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
> 
>