Re: Backward compatibility

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:

> Hi,
>
> 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 [1].
> 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, 
etc.).
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.

Stefan

--
       ...ich hab' noch einen Koffer in Berlin...