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