Re: Backward compatibility

Subject: Re: Backward compatibility
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-07-04 22:46:12

On 07/04/18 18:01, Mateusz Loskot wrote:
> On 4 July 2018 at 18:04, Stefan Seefeld <stefan_at_[hidden]> wrote:
>> It remains however to be
>> defined what exactly that means (including to what degree we want to enforce
>> compatibility, establish deprecation policies, etc.).
> Indeed.
>
> I think Boost.TypeTraits & MPL clean up [1] may be a useful exercise
>
> [1] https://github.com/boostorg/gil/pull/107
>
>> 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.
> I still think we may want to familiarise ourselves with [2] as the
> outcome of [3]
>
>     "Large breaking changes that are equivalent to a redesign or
>      rewrite of the library should be treated as a new library
>      and a formal review (or at least a mini review) is encouraged."

I think the context of that advise is very different. In my
interpretation this is merely a way bring home the point that Boost
libraries are peer-reviewed. So, if You submit a proposal of a new
library A, but then entirely remodel it to become B, you shouldn't just
conclude that because A was accepted that this gives you licence to add B.

The problem with compatibility is much more subtle...

>
> Aa well as with alternative takes on compatibility like [4] suggested
> by Peter Dimov.
>
> [2] https://github.com/boostorg/website/pull/300/
> [3] https://lists.boost.org/Archives/boost/2017/12/240108.php
> [4] https://lists.boost.org/Archives/boost/2017/12/240117.php

Well, I don't like that advice, to be honest. Proliferating APIs is just
one problem. But the more problematic one is that it doesn't really
solve any issue: If we (one day) release GIL2, we'd either have to
maintain two libraries (GIL and GIL2), or we'd (implicitly or
explicitly) deprecate GIL. And given that users can always stick to
prior Boost releases if they really need that older version of GIL, I
don't see the point in releasing 'GIL2'.

The real problem really is that Boost totally lacks any form of
compatibility policy, so Boost-N and Boost-N+1 are two distinct sets of
libraries. (And I think that's what Peter is referring to when he states
"semantic versioning is useless in the Boost context".
And given that Boost.GIL is still using quite a number of other Boost
libraries, we can try as much as we want to be backward-compatible. As
soon as any of the prerequisite libs isn't, we aren't.

That's why I suggested that we *should* care for backward-compatibility,
but that's only ever going to be possible if / when our prerequisites do.

>> 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.
> Yes, I agree and, as already explained, that is what I'm setting as my priority.

Right, I understand. (Forgive me for the rant above, I'm just trying to
spell things out explicitly for the record, and because now I feel
slightly better. :-) )

Stefan

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