[dpdk-dev] [PATCH v3 4/4] docs: Add ABI documentation

[Neil Horman]

On Wed, Jan 14, 2015 at 04:59:51PM +0100, Thomas Monjalon wrote:
> 2014-12-23 10:51, Neil Horman:
> > Adding a document describing rudimentary ABI policy and adding notice space for
> > any deprecation announcements
> 
> We had a good discussion about the policy and its impact:
> 	http://thread.gmane.org/gmane.comp.networking.dpdk.devel/8367/focus=8461
> Sadly nobody else discussed it.
> I think we should integrate some of the conclusions in this documentation.
> 
I'm certainly open to that.  However, I felt like that conversation centered
more around the debate for the need for ABI versioning, not the mechanics
thereof.  Are there specific sections of that conversation that you are looking
to incorporate, or specific topics?

> > --- /dev/null
> > +++ b/doc/abi.txt
> > @@ -0,0 +1,17 @@
> > +ABI policy:
> > +	ABI versions are set at the time of major release labeling, and ABI may
> > +change multiple times between the last labeling and the HEAD label of the git
> > +tree without warning
> > +
> > +	ABI versions, once released are available until such time as their
> > +deprecation has been noted here for at least one major release cycle, after it
> > +has been tagged.  E.g. the ABI for DPDK 1.8 is shipped, and then the decision to
> > +remove it is made during the development of DPDK 1.9.  The decision will be
> > +recorded here, shipped with the DPDK 1.9 release, and actually removed when DPDK
> > +1.10 ships.
> > +
> > +	ABI versions may be deprecated in whole, or in part as needed by a given
> > +update.
> > +
> > +Deprecation Notices:
> > +
> 
> You could upgrade your example to 2.0/2.1.
> 
Sure, though I think doing so is rather arbitrary, as its going to be
immediately dated as soon as version 2.1 releases.  But I can do that if you
like when we square up the documentation question above
Neil

> Thanks
> -- 
> Thomas
>