[ofiwg] post OFI 1.0

[Weiny, Ira]

> 
> > > * Should releases be 1.1, 1.2, 1.3, etc. or 1.0.1, 1.0.2, 1.0.3?
> >
> > One random point: this might be useful reading when considering
> > versioning
> > schemes:
> >
> >     http://semver.org/
> 
> That site would suggest that most libfabric releases over the next couple of
> years will be of the form 1.y.

I think that is a good thing!

> 
> 7.Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
> compatible functionality is introduced to the public API. It MUST be
> incremented if any public API functionality is marked as deprecated. It MAY be
> incremented if substantial new functionality or improvements are introduced
> within the private code. It MAY include patch level changes. Patch version
> MUST be reset to 0 when minor version is incremented.
> 
> Most (all?) of the OFA packages bump only the lower number for new releases,
> except for the OFED package which aligns with the base linux kernel number.
> Hence*, why I'm bringing this up.

Actually for the *.so versions we do bump the Y version and unfortunately we have even bumped the X version.  :-(

I have never liked that the OFA package versions don't equal the *.so version...

If my vote counts for anything I vote to use the semantic versioning (3 numbers) and have the package number == the library *.so version.

I understand that sometimes you just have releases with documentation or build changes which don't change the library code itself.  But this is rare and one could consider those changes as a simple "PATCH" versions which incrementing the *.so patch version will not affect.

Ira


> 
> The exception is that the next release after 1.0 may be either 1.0.1 or 1.1,
> depending on how much content can be completed within the next 2 months.
> 
> - Sean
> 
> 
> * 3 points to Ravenclaw for using the word hence in an email
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg