Boost logo

Boost :

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 :(


Boost list run by bdawes at, gregod at, cpdaniel at, john at