Boost logo

Boost :

Subject: [boost] [SPAM] Re: Policy for breaking changes
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2017-12-04 03:10:16

> 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.


Sent from:

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