Boost logo

Boost :

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.

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