Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk