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