Re: [boost] Policy for breaking changes

Subject: Re: [boost] Policy for breaking changes
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-12-03 16:51:28

On 12/2/17 1:44 PM, Louis Dionne via Boost wrote:
> Hi all,
> 
> So far, I've been careful about not doing any breaking changes to Hana.

I'm a little unclear what "breaking" might mean here.  Here are couple 
of different scenarios.  A change might result in any the following:

a) calls into the API return exactly the same value.  This would be 
something like a bug fix or performance enhancement.  Clearly this 
change wouldn't break anything.

b) some enhancement like a new (meta)function is made available.  This 
updates code and documentation but doesn't break any application which 
uses the library.

c) some change which alters the API in a way that previous applications 
fail to compile.  Clearly this is a "breaking change".  But I would 
argue that it's totally innocuous.  Using the new version of the library 
trips a compile error which would mean that the library user has to 
update his code.  He might not be really happy about this, but it's not 
going to cause any harm.

d) silently changing what some library function does. uh-oh.  Here one 
is going to have one testy user.  I would recommend create a 
function/type with a new name.  The old name can be removed if you want 
so this situation decays into c) above.  Maybe not a happy user, but he 
suffers only a minor inconvenience.

e) some change which has an effect previous usages of the library.  The 
classic case is the serialization library where corrections/enhancements 
of the library code have to be done in such a way that previously made 
data archives are still readable.  This can sometimes be a big issue.

In sort, I don't see the need for something like "Hana2" unless the 
changes are so extensive that is effectively a whole new library.  If 
this is the case, it raises a bunch of other questions.  An example is 
spirit library.  We have spirit, spirit1, and spirit3 which are quite 
incompatible with each other.  Only now have I learned that spirit3 is 
not yet totally "ready" - after many years of being in boost.  I'm 
wondering if such cases shouldn't be considered as a new library subject 
to the same review requirements as any new library would be.

Finally, I see hana as very niche library which is not in wide usage in 
user code.  So it's not clear how many people would be effected by 
"breaking" changes. If it were 10 people I'd say we should just let the 
author deal with it.  If it's 100,000 people, it should be handled 
differently.  Unfortunately, we have absolutely no useful information 
regarding how widely any particular library is actually being used. It 
would be useful to have such information for cases like this as well as 
for many others.

Robert Ramey