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