Re: Backward compatibility

Subject: Re: Backward compatibility
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-07-04 16:02:50

On 4 July 2018 at 15:46, Christian Henning <chhenning_at_[hidden]> wrote:
> On Wed, Jul 4, 2018 at 8:14 AM Mateusz Loskot <mateusz_at_[hidden]> wrote:
>>
>> 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.
>
> Priority wise I think we need to work on the API. We need to include boost
> and other c++ experts. But in general, we need to answer the question what
> we want from gil? Do we just want the core and the ability for extensions?

Although those are valid priorities and questions indeed,
myself I do not feel confident to make any API or functional changes
for as long as I have no idea what the tests are doing,
what areas of the current API the tests actually verify,
what areas are not covered, etc.
The current tests give very limited or no feedback.
IMHO, we are going to entangle ourself in deep troubles if re-design or
re-implement without having a safety harness we can rely on.
It does not have to be 100% coverage, but the coverage we have
should be comprehensible and verifiable.

> The core being sort of a STL for 2D data or do we want to include 3D?
>
> I think we should stick with the concepts that gil already provides and
> take that as a starting point.
>
> There are ideas here: https://github.com/boostorg/gil/wiki/Boost.GIL-3-Ideas

I am not able to offer time and resources to strip off GIL from everything but
the framework of concepts and re-implement everything just based on
that skeleton.

We have to be realistic in terms of planning without overshooting and
in terms of achieving. For that, we have to take baby steps:
- divide into small tasks, iteratively as we go, not planning upfront
then do the work
- complete the small tasks
- conquer

Those are slightly off-topci for this thread, so let's discuss as we go.

> I would advise against backward compatibility.

This is an important comment Christian that I was looking for.

Although I'm generally in favour of not promising any backward compatibility,
we need to consider a few issues:

Advantages/Opportunities:
- Helps to better exploit our limited resources we can invest in GIL
- Helps to lower maintenance overhead
- Helps to focus and complete priority tasks and move forward with the project

Disadvantages/Threads:
- Maintenance overhead
- For as long as GIL is part of Boost, we may need to follow global policies [2]
- Users may hate us and avoid using GIL
- Users to-be contributors may never arrive due to the former
- Contributors may leave

[2] https://github.com/boostorg/website/pull/300
-- 
Mateusz Loskot, http://mateusz.loskot.net