Re: [dpdk-dev] versioning and maintenance

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Nov 19, 2014 at 11:35:08AM +0000, Bruce Richardson wrote:
> On Wed, Nov 19, 2014 at 12:22:14PM +0100, Thomas Monjalon wrote:
> > Following the discussion we had with Neil during the conference call,
> > I suggest this plan, starting with the next release (2.0):
> > 	- add version numbers to libraries
> > 	- add version numbers to functions inside .map files
> > 	- create a git tree dedicated to maintenance and API compatibility
> > 
> > It means these version numbers must be incremented when breaking the API.
> > Though the old code paths will be maintained and tested separately by volunteers.
> > A mailing list for maintenance purpose could be created if needed.
> >
> Hi Thomas,
> 
> I really think that the versionning is best handled inside the main repository
> itself. Given that the proposed deprecation policy is over two releases i.e. an
> API is marked deprecated in release X and then removed in X+1, I don't see the
> maintaining of old code paths to be particularly onerous.
> 
> /Bruce
> 

I agree with Bruce, even if it is on occasion an added workload, its not the
sort of thing that can or should be placed on an alternate developer.  Backwards
compatibility is the sort of thing that has to be on the mind of the developer
when modifying an API, and on the mind of the reviewer when reviewing code.  To
shunt that responsibility elsewhere invites the opportunity for backwards
compatibilty to be a second class citizen who's goal will never be reached,
because developers instituting ABI changes will never care about the
consequences, and anyone worrying about backwards compatibility will always be
playing catch up, possibly allowing ABI breaks to slip through.

Neil