Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)

Subject: Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
From: Stephen Kelly (hello_at_[hidden])
Date: 2015-10-07 13:09:14

Rob Stewart wrote:

> On October 6, 2015 2:36:05 PM EDT, Stephen Kelly <hello_at_[hidden]>
> wrote:
>> Rob Stewart wrote:
>> > On October 5, 2015 1:51:57 PM EDT, Stephen Kelly
>> <hello_at_[hidden]>
>> > wrote:
>>
>> >> 2) Why not let people fork it to Boost.TestLegacyVersion if they
>> want
>> >> legacy compatibility? Why suggest that the new version be 'the
>> fork'?
>> >> Why
>> >> not fork for legacy and drop the legacy when the time for doing
>> >> that comes?
>> > 
>> > Forcing all other projects to make changes is more work than forking
>> > The one project.
>> 
>> Can you qualify what 'all other projects' means?
> 
> I don't have a specific number at hand, but I'm referring to all of the
> Boost projects that rely on Boost.Test for their tests. 

Ok, thanks! You're only thinking about in-tree consumers of the library!

> The tests for
> every one of those projects would have to be modified to reference a new
> library. That means changing include directives and link information.

I don't know aything about the boost buildsystem, but I am surprised that is 
difficult.

> Furthermore, those maintainers would have to find someone to create the
> legacy fork to even make that possible.

I'm surprised that is difficult too. Seems like something mostly mechanical.

It also seems kind of reasonable that the people who want a legacy library 
could create it... It is clear that whoever changed Boost.Test has already 
moved with the times :).

>> >> 3) Why make users change their code to use 'Test2' instead of
>> >> 'Test', and  then to 'Test3' in the future?
>> > 
>> > That allows users to opt in to the changes.
>> 
>> You seem to prefer to punish those people who have already moved with
>> the
>> times :). Or would they otherwise have to do something too?
> 
> How is wanting the Boost.Test maintainers to create a fork, make all the
> banking changes they like to form a new library, and then offering that
> library punishment? 

External (not in-tree) consumers of boost have moved with the times. On this 
mailing list that is not clear as everyone here likes to use GCC 4.1 and 
MSVC 7.1 apparently :). 

But yes, the reality is that many many projects not in the boost tree use 
GCC 4.8 and later and MSVC 2012 and later. They can use Boost.Foo today, 
which might conditionally use modern C++ features. 

If Boost.Foo some day increases compiler requirements, then it is apparently 
a requirement to create Boost.Foo2 (Rob, note that you are responding to my 
question to Edward here:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/263519/focus=263572
)

If the requirement is that a fork is created, then some group is 'punished' 
with having to follow the rename. You want to punish the people who have 
already moved with the times.

> The appropriate alternative is to announce that
> breaking changes are coming, use conditional compilation to opt in to the
> changes for several releases, then make the changes the default and use
> conditional compilation to opt out for several more releases, and finally
> drop the original. 

That seems like a reasonable thing to do, but it is not what we are talking 
about :). See that we are talking about Edwards suggestion to create a fork 
library for the new compiler requirements:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/263519/focus=263572

That is what we are talking about. The suggestion is to fork with a new name 
when updating compiler requirements. That has come up before:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/257194/focus=257295

> That is how numerous other libraries manage the issue.

Yes, it seems like one of many reasonable approaches.

> In many ways, that's harder on the maintainers, but it does preserve the
> library name and avoids the likely need for a review of a fork.

Yes, preserving the library name is good :). That's what we are discussing 
:).

Thanks,

Steve.