On 12/03/2017 02:18 AM, Vicente J. Botet Escriba via Boost wrote:
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.
Spirit did something like that. It has an x3 version and a qi version
of it's code. The x3 version is used with:
#include