Re: [boost] Policy for breaking changes

Subject: Re: [boost] Policy for breaking changes
From: Larry Evans (cppljevans_at_[hidden])
Date: 2017-12-03 10:07:01

On 12/03/2017 02:18 AM, Vicente J. Botet Escriba via Boost wrote:
> Le 02/12/2017 à 22:44, Louis Dionne via Boost a écrit :
>> Hi all,
>>
>> So far, I've been careful about not doing any breaking changes to Hana.
>> Hana obeys semantic versioning, and I'm accumulating desirable breaking
>> changes until I'm ready to publish a new major version.
>>
>> I'm wondering what's the policy for major breaking changes with Boost
>> libraries. For example, let's say I wanted to do an update of Hana with
>> C++17 features; this would be a large breaking change, with all kinds
>> of API changes, etc..
>>
>> - Are such drastic changes prohibited altogether? Or perhaps they’re not
>>    prohibited but there’s historical evidence showing it’s always a bad
>> Â Â  idea?
>> - Do such changes require going through a mini review?
>> - Is it customary to leave the old version of the library there in a
>> Â Â  separate directory (or put the new one in a separate directory)?
>> Â Â  I think Spirit does that, e.g. Spirit Classic is still available IIRC.
>>
>> I think I know the answer to these questions from observing other 
>> author's
>> behavior, but I'd like to see what the community thinks about this. It 
>> has
>> an impact on the Boost libraries as a whole, since a major breaking 
>> change
>> in one library could prevent users from updating Boost as a whole, which
>> has an impact on all of us.
>>
>> I'm looking forward to hearing other people's thoughts on the matter.
>>
> 
> Hi Louis,
> 
> do you want to break the users code with your changes?
> I don't believe, you could want it.
> 
> do you want to maintain two versions of your library?
> 
> If yes, do you want to require that all the parts of an application uses 
> the same library version?
> I suggest to don't do that, you will lost users.
> 
> If you want to make it possible to have two version of Boost.Hana, I 
> believe the best is to take a new folder and a new namespace, as 
> Boost.Spirit.
> 
> I've not do that. I did a really bad work with Boost.Thread/Chrono and 
> I'm paying for it.
>

Spirit did something like that.  It has an x3 version and a qi version
of it's code.  The x3 version is used with:

#include <boost/spirit/home/x3.hpp>

I don't know how well that went.  One thing to guard against
is to make sure you don't duplicate #include guards.  Spirit
x3 didn't and that led to minor problems when trying to use
the qi as well as the x3 versions of code :(

-regards,
Larry