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

  Adding a document describing rudimentary ABI policy and adding notice space for
any deprecation announcements

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Thomas Monjalon <thomas.monjalon@6wind.com>
CC: "Richardson, Bruce" <bruce.richardson@intel.com>
---
 doc/abi.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 doc/abi.txt
  

On Tue, Dec 23, 2014 at 10:51:53AM -0500, Neil Horman wrote:
> Adding a document describing rudimentary ABI policy and adding notice space for
> any deprecation announcements
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Thomas Monjalon <thomas.monjalon@6wind.com>
> CC: "Richardson, Bruce" <bruce.richardson@intel.com>
> ---
>  doc/abi.txt | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 doc/abi.txt
> 
> diff --git a/doc/abi.txt b/doc/abi.txt
> new file mode 100644
> index 0000000..b6dcc7d
> --- /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:
> +
> -- 
> 1.9.3
>
Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
  

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.

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

Thanks
  

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
>
  

2015-01-14 15:07, 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?

Yes.
In the point number 2, you suggest to skip ABI compatibility (after a
deprecation schedule) for big changes.
In the point 3, you suggest to add new fields at the end of the structure,
even if it's asthetic, with exceptions if performance impact.

Thank you