Re: Backward compatibility

Subject: Re: Backward compatibility
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-07-04 22:58:30

On 5 July 2018 at 00:46, Stefan Seefeld <stefan_at_[hidden]> wrote:
> 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.

It makes sense. What made me wondering is that A to B transition
called remodelling or not seems to/may be based on subjective grounds.

>> 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'.

That is indeed what I have experienced or learned from Boost so far.

> 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".

Right, it makes sense.

> 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.

OK. That addresses my own questions pretty well.
I'd agree if GIL backward-compatibility policy, if you will :)
is premised on this.

>>> 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. :-) )

None taken as a rant. All your comments are very helpful and appreciated :)

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net