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.