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: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-10-07 04:38:53

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. 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. Furthermore, those maintainers would have to find someone to create the legacy fork to even make that possible.

> >> 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? 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 is how numerous other libraries manage the issue. 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.

___
Rob

(Sent from my portable computation engine)