Jeff Garland wrote:
I'm ok with supporting the new Borland compiler if we get someone to regression test it.
That is my key concern, and I believe testing resources will be in place for the 1.34 testing cycle. So long as the newer compiler is supported, my concern for BCB6 is the same as for VC6 and GCC2.95 - one version notice of 'deprecation'.
I don't see the issue this way. The main problem for library authors is that any new code changes might break the fragile workarounds that keep regression tests working for Borland. Then a note needs to go in some documentation to explain this feature isn't available, etc. So with every change we are 'walking on eggshells'. It's this time that I want poured into new library development instead.
I understand. I wish I wasn't in the position of asking for this stuff ;?) I am very happy for new libraries to only target conforming (or close) compilers - although if I find easy patches you can be sure I will be trying to submit them <g> I still haven't entirely given up on finding workarounds for the graph library ...
I don't agree. If at some future point Borland comes up with a new compiler that is better I think we would welcome it and support it vigorously.
I think you misunderstood me here. The point is that every time Borland produce a new compiler, there is no 'old version' of *Boost* for customers to fall back on for legacy support. They need a new config, and some workarounds updating to check for the new compiler version. It doesn't help Borland has some of the nastiest configs, with 3 different standard library suppliers in the last 3 releases, a public beta compiler with a higher version number than the actively maintained product line, a brief flirt with a Linux compiler, and at least one version supporting two different Standard Libraries requiring distinct workarounds. I look forward to retiring a lot of these older workarounds as much (if not more) than anyone! -- AlisdairM