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

Rob Stewart wrote:

On October 6, 2015 2:36:05 PM EDT, Stephen Kelly wrote:

...

Rob Stewart wrote:

...

On October 5, 2015 1:51:57 PM EDT, Stephen Kelly 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.