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

[Fab Tillier]

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?

> -----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