Boost logo

Boost :

Subject: Re: [boost] Policy for breaking changes
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-12-03 08:18:53


Le 02/12/2017 à 22:44, Louis Dionne via Boost a écrit :
> 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.
>

Hi Louis,

do you want to break the users code with your changes?
I don't believe, you could want it.

do you want to maintain two versions of your library?

If yes, do you want to require that all the parts of an application uses
the same library version?
I suggest to don't do that, you will lost users.

If you want to make it possible to have two version of Boost.Hana, I
believe the best is to take a new folder and a new namespace, as
Boost.Spirit.

I've not do that. I did a really bad work with Boost.Thread/Chrono and
I'm paying for it.

I don't think we are requiring a review for each major version change,
but if you consider that the library changes is a redesign, it would be
a good idea to have a review.

Vicente


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