Re: [boost] [SPAM] Re: Policy for breaking changes

Subject: Re: [boost] [SPAM] Re: Policy for breaking changes
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-12-04 08:57:28

On 12/04/17 06:10, Louis Dionne via Boost wrote:
> 
>> 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..
>> [...]
> 
> Thanks everyone for the feedback, it's quite useful and it crystallizes
> some of the expected behavior for Boost authors. Here's a summary
> of what I got away from the answers:
> 
> 1. Non-breaking changes can be done without restriction.
> 2. Small breaking changes can be made, but users should be given
>     notice a few releases before the change is published.
> 3. For large breaking changes WITH a migration path from
>     before-the-change to after-the-change (e.g. filesystem v2 -> v3),
>     the change should be made by providing the functionality in a
>     separate directory/namespace, and users should be given a few
>     releases to move over. The before-the-change functionality can
>     be removed after some time.
> 4. For large breaking changes WITHOUT a migration path
>     (e.g. spirit 2 -> 3), the change should be made in a
>     separate directory/namespace, and the before-the-change
>     state should be preserved (because there's no migration path).
> 5. If a large change falling into categories (3) or (4) is
>     equivalent to a redesign or rewrite of the library, this
>     should be treated as a new library and a formal review
>     (or at least a mini review) is encouraged.
> 
> Please correct me if I got something wrong. Would it be
> useful to document this officially somewhere on the Boost
> website? Is it desirable for Boost to adopt some kind of
> "official stance" on this matter (for now none of this is
> normative)? I can submit a PR to add the documentation if
> I only know what module I must submit it to.
> 
> As far as Hana is concerned, I think the logical thing for me
> to do is to proceed by way of small breaking changes with a
> deprecation period, at least for the time being.

I think, this is ok, but only as long as the affected functionality of 
the library will be still usable in C++14, i.e. C++17 features are 
completely optional.