Subject: Re: Backward compatibility
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-07-04 16:04:52
On 2018-07-04 08:13 AM, Mateusz Loskot wrote:
> We're shaking off the Grand Merge, releasing
> significant GIL update with Boost 1.68 and
> soon we will be able to move forward (towards GIL 3?).
> I've already started removing lots of dependencies
> from Boost itself, replacing them with C++11.
> The one more challenging is removal of Boost.TypeTraits
> and some bits of MPL .
> This experience made me wonder how we should approach
> significant changes in the API, structure of public headers, etc.
> for backward compatibility.
So far we were using the fact that GIL hasn't received updates in years
as rationale for not caring much about backward compatibility. However,
moving forward the hope is of course to (re-?)build a GIL user
community, so we definitely should care for API compatibility. It
remains however to be defined what exactly that means (including to what
degree we want to enforce compatibility, establish deprecation policies,
But since Boost itself doesn't provide any backward compatibility
guarantees, I think it will be difficult to provide guarantees as long
as we depend on Boost as much as we do now. Thus, our priority should be
to reduce our dependency on Boost as much as possible, at which point we
are in a much better position to become backward compatible.
As far as header structure is concerned, I think for the core library we
should establish `boost/gil.hpp` as the only public header, so we are
free to restructure anything inside boost/gil/ without concern for
users. Likewise, extension APIs should each have their own top-level
header (e.g. `boost/gil/extension/io/png.hpp` for the PNG IO extension)
as the public entry point, and anything else is implementation detail.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by Boost-Gil-Owners