Re: [boost] Policy for breaking changes

Subject: Re: [boost] Policy for breaking changes
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-12-02 21:52:38

On 12/2/2017 4:44 PM, 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..
> 
> - Are such drastic changes prohibited altogether? Or perhaps they’re not
>    prohibited but there’s historical evidence showing it’s always a bad
>    idea?
> - Do such changes require going through a mini review?
> - Is it customary to leave the old version of the library there in a
>    separate directory (or put the new one in a separate directory)?
>    I think Spirit does that, e.g. Spirit Classic is still available IIRC.
> 
> I think I know the answer to these questions from observing other author's
> behavior, but I'd like to see what the community thinks about this. It has
> an impact on the Boost libraries as a whole, since a major breaking change
> in one library could prevent users from updating Boost as a whole, which
> has an impact on all of us.
> 
> I'm looking forward to hearing other people's thoughts on the matter.

If the breaking change is not part of the private API usually you notify 
end-users for at least one Boost release, before making the change in a 
subsequent Boost release. This also includes C++ level requirements.

If the breaking change is private, then no matter what it is I see that 
as something the maintainer of a library can do at any time.

As far as providing major changes to non-private functionality as a 
whole new "release" of the library, then it is up to the maintainer if 
he wants to still provide a backward compatibility layer. But once 
again, whatever the decision, if the end-user has to do something 
differently to use the library as he did before, I think my first 
paragraph answer should still be in effect.

> 
> Thanks,
> Louis