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

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.

Thanks!
Louis

--
Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html