Robert Ramey wrote:

Any library author has the authority to decide which platforms he will support. Boost only requires that code be conformant with the C++ standard. Its not something that requires or even permits a communal decision.

I second that. Deprecation for a compiler should be manageable per library author. (See also my other post). Roland

"Robert Ramey" <ramey@rrsd.com> wrote in message news:e3fo20$8sl$1@sea.gmane.org...

Personally, I think the whole concept of "deprecation" is dead end.

Any library author has the authority to decide which platforms he will support. Boost only requires that code be conformant with the C++ standard. Its not something that requires or even permits a communal decision.

I do not agree it's proper way looking at that. IMO "deprecation" has nothing to do with library itself. What it has to do with is what you test a library on. IOW whether or not any particular library works on any particular platform is irrelevant. What is relevant is whether library is *tested* of that platform. From this prospective deprecation means that particular platform is excluded from testing. That does not mean that library will stop working on that platform. But it means that "all bets are off". In addition it's possible to deprecate any particular library on any particular platform we do perform testing. The current mechanism for that is to mark platform as unsupported in test results view ( I am not sure whether the actual test are going to be performed, anyone?). [...]

Example, the serialization library compiles and passes almost all test with bib 5.51. Who is to tell me that it should or should not do that.

Nobody. But if boost stops testing on this platform that platform is deprecated. Now if you are interested enough to keep this platform from deprecation you should either argue against dropping testing or volunteer to perform testing yourself..

Now the new boost.test library will no longer support this platform. Hence I have two choices stop testing with bib 5.51 or avoid usage of boost test. This is a decision I'll have to make on my own.

As I explained earlier Boost.Test will continue privide support for Boost regression on all active platforms (IOI on all platforms that are not deprecated) Gennadiy

"David Abrahams" <dave@boost-consulting.com> wrote in message news:ulktgbcqp.fsf@boost-consulting.com...

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

...

I do not agree it's proper way looking at that. IMO "deprecation" has nothing to do with library itself. What it has to do with is what you test a library on.

Sorry, you've all got it wrong :)

I think we just having terminology misunderstanding.

Deprecation indicates an intention to stop supporting a particular construct or usage, sometime in the future.

You may refer to "feature/construct deprication" in relation to a library functinality. You may refer "compiler deprication" in relation to set of compilers/configurations a library is tested on. You may refer to "support deprication" in relation to set of compilers/configurations supported by a library. First and third kinds managed excusively by library authors. Second - by the fact which compiler boost performed testing on.

Deprecation is not a dead end. It is a good thing, because it allows us to break code in the service of better libraries, by giving users fair warning. Whether Boost as a whole can deprecate the use of a given compiler is another matter.

Here we agree. Gennadiy

Robert Ramey wrote:

Given this, along with the fact that library authors actually do have varying support for different compilers make the whole discussion irrelevant.

Example, the serialization library compiles and passes almost all test with bcb 5.51. Who is to tell me that it should or should not do that.

This is useful, but the trouble we run in to is that one library drops support for a compiler in a particular version and no matter what other libraries still support that compiler, we can't move to a later release because we depend on a library that the author has dropped support for. So given 99% of the libraries still support our compiler, the fact that one library now doesn't means none of that version of boost is useful to us. Also, there never seems to be a dead-easy way for an end user to find out which libraries dropped/added support for which compilers in particular releases. We got hit by this because ublas dropped support for Borland in 1.32.0. I've managed to get bits of ublas working in 1.32.0 now so we have moved to it, but this doesn't look possible for 1.33.0 so we are now stuck on BCB6 and 1.32.0. I realise this isn't boot's (or its developers) fault that Borland haven't managed to increase the conformance of their compiler, but it would be very helpful if there was more information easily available to which libraries support which compilers and especially in the main release notes when compilers get added/dropped. Cheers Russell

Nicola Musatti wrote:

One thing I do feel strongly about: no matter how broken a library is with a specific compiler, deprecation advertising should entail a warning and not an error.

Howerver #error is all that we have in place today. For instance, Spirit refuses to work with BCB by using a #error, as does uBlas. Borland config refuses to support BCB3 or earlier by using #error. Essentially I am proposing a warning to appear the version before support is dropped, and a way to acknowledge / disable that warning.

It would also make it possible to accept platform specific patches against previous releases of Boost and maybe even allow more bugfix releases, should anybody volunteer to perform the necessary tasks.

So long as the release branch remains available in CVS, that should always be possible. Arranging for it to work **and be regression tested** might be more difficult.

A concrete example: I'm using Borland's BCB6 at work and we're stuck with Boost 1.31 because we're using uBlas, which doesn't support my compiler in more recent releases. Now I happen to know that 1.32 "almost" works and that someone has the necessary patches. Accepting these to be committed against the 1.32 branch would enable all those in my situation to at least move forward one release (I happen to know that there are at least two of us - right, Russell? :-).

As a committed Borland user myself I definitely feel your pain. I also think 1.34 could be a very important release for older Boost platforms, not just because it is the last to officially test them, but because of the std::tr1 support John Maddock has put in. This may be the only tr1 implementation available to them. Even though these are among the oldest and most stable libraries in Boost, there were some fixes checked in for better MS support on old compilers in type traits just for this release! But in the general case I believe the best way to support old compilers is to point to the last supporting Boost release. Several library maintainers were looking to drop support for the listed compilers in this release, and some are actively looking to clean up thier codebase and remove workarounds. A deprecation release was the agreed compromise - so platform supporters get notice and one whole release to really bang in any bug fixes they can find. After that, with the dwindling pool of supported libraries I believe the best we can do is point back to the last tested/supported release. I admit I would like to go further and make that a #error in the Borland config with a message pointing to 1.34, and clear out the legacy support for 3 different standard libraries etc. I am anticipating library maintainers to be doing the same, which is why we should also focus on updating all the BOOST_TESTED_AT macros to test agaist the correct version - in case 'old' workarounds get removed that we are still relying on to support the latest compiler. -- AlisdairM

Nicola Musatti wrote:

I don't agree. Why remove a support that is there and has been through several Boost releases? I understand that library authors wishing to evolve their libraries are entitled to choose which compilers they plan t osupport and the amount of effort they wish to devote to supporting obsolete compilers, but if it works, why break it?

Because, I have to maintain several versions of code that have the potential for different bugs. In date_time the from_string/to_string methods were written early on and were carefully crafted to work with VC6, Borland, etc. Even now, like yesterday actually, a new failure mode will show up in these functions. In the meantime, I've completely rewritten the i/o subsystem -- it's much more flexible and robust. It supports wide chars, is heavy on templates, and breaks on a bunch of old compilers -- basically it's disabled on all the legacy compilers. Now I could trivially rewrite the from_string/to_string using the new i/o code and fix any issues in one place, but I can't do it without breaking old compiler support. In addition, I have a second variant of i/o code on the old compilers to maintain and fix bugs for. And last, but not least, the only reason date_time isn't header-only at this point is the legacy i/o code. So all of this is a big pain for me and that's why I'm so vocal about this release being the end of the line for date_time support of old compilers and standard libraries. When I look at the global boost situation it pains me to see library authors dedicated to defining and evolving the future of C++ spending their time trying to make these non-compliant tools work. Every minute they spend adjusting for the old compilers is a minute taken away from something better for the future of C++ programmers overall. It's my judgment overall that we've crossed over the line where it's far better for us to focus on the future rather than the past. A Boost-wide deprecation of the old compilers/standard libs takes the brakes off the forward progress. BTW, as a little note of history, when I first used Boost 5 or 6 years ago now, many of the libraries were only 'marginally portable' -- mostly because typical compilers of the day were VC6 and g++ 2.93. All sorts of libraries broke different compilers in different ways. The standard libraries of the day were mostly just bad. Now we have a whole breed of excellent compilers/standard libs that will compile and run a much larger collection of Boost libraries. This is a huge leap forward from where we were. I believe part of that progress was brought about by Boost "pushing things" forward. The way I see it, without Boost continuing to push, much of the life would come out of the C++ evolution. I want to maximize the push now because we still have much work to do. Jeff

Nicola Musatti wrote:

One thing I do feel strongly about: no matter how broken a library is with a specific compiler, deprecation advertising should entail a warning and not an error.

This would make it more easy to un-deprecate a platform when it starts supporting the required constructs and enables library authors to accept platform specific patches on a discretionary basis. Moreover even if such patches were not submitted/accepted developers would be free to try and use those portions of a library that do work on their platform.

It would also make it possible to accept platform specific patches against previous releases of Boost and maybe even allow more bugfix releases, should anybody volunteer to perform the necessary tasks.

A concrete example: I'm using Borland's BCB6 at work and we're stuck with Boost 1.31 because we're using uBlas, which doesn't support my compiler in more recent releases. Now I happen to know that 1.32 "almost" works and that someone has the necessary patches. Accepting these to be committed against the 1.32 branch would enable all those in my situation to at least move forward one release (I happen to know that there are at least two of us - right, Russell? :-).

Further to the ublas patches, I'd also like to look at back-porting your bcbboost work to the 1.32 branch which would enable us to possibly move to BDS2006 with boost-1.32.x. But at the moment, like you, we are stuck on BCB6 and boost-1.32.0 with our ublas patches until Borland releases a compiler that can handle the later versions (which I don't see happening anytime soon given that BDS has only just been released). Unfortunately I'm not going to be able to look in to this for a while but it is certainly on my to do list as I'd actually like to be able to evaluate bds on a real project, not just little bits of test code which I'm limited to at the moment. Cheers Russell

AlisdairM wrote:

Playing devil's advocate here!

What is the benefit of doing this in the main Boost CVS, as opposed to maintaining another bcbboost_1_32?

I doubt we are going to see another patched release of Boost 1.32 at this point, the regression testing cost alone is likely prohibitive.

By maintaining a separate BCBboost aimed purely at BCB customers, and QAing against BCB6 and 2006 only, it is easier to perform necessary testing and get it back into the hands of Borland customers.

You could also integrate Spirit 1.6 as the default version of the library at that point too.

I doubt it too, and wouldn't mind where it came from. It could be done again as a separate project (in fact, we import each boost release in to our own svn repository at work and modify it and version internally ourselves). But I'd rather see it done as a complete source tree, rather than a patch as bcbboost is. i.e. if we are to do this, then import the current boost-1.32.0 in to a new svn repo at sourceforge and then modify that. But if there aren't many people requiring this, then perhaps it is overkill. If I get the chance to look at getting 1.32.0 working with BDS 2006 internally then that is a start. Once that is done, I can think about how to make it more public. Integrating spirit as the default would be a good move too (again, that is what our svn repo of boost contains). Cheers Russell

On 2006-05-06, AlisdairM <alisdair.meredith@uk.renaultf1.com> wrote:

...

Further to the ublas patches, I'd also like to look at back-porting your bcbboost work to the 1.32 branch which would enable us to possibly move to BDS2006 with boost-1.32.x. Playing devil's advocate here! What is the benefit of doing this in the main Boost CVS, as opposed to

Russell Hind wrote: maintaining another bcbboost_1_32? I doubt we are going to see another patched release of Boost 1.32 at this point, the regression testing cost alone is likely prohibitive.

There is something else that has to be considered: if you release bcbboost you don't have to worry about introducing regressions in to the other, supported, compilers. Your workarounds can be ones that would *never* be accepted as part of the main boost because of the breakages they would introduce. As you say, it will be much simpler to QA a release aimed just at this compiler. Speaking as somebody who got stuck on a crappy compiler with a specific version of boost for 3 years, I can sympathise with seeing all the wonderful new libraries being added to boost and not being able to use them :-) phil -- change name before "@" to "phil" for email

AlisdairM wrote:

Russell Hind wrote:

...

Further to the ublas patches, I'd also like to look at back-porting your bcbboost work to the 1.32 branch which would enable us to possibly move to BDS2006 with boost-1.32.x. But at the moment, like you, we are stuck on BCB6 and boost-1.32.0 with our ublas patches until Borland releases a compiler that can handle the later versions (which I don't see happening anytime soon given that BDS has only just been released).

Playing devil's advocate here!

What is the benefit of doing this in the main Boost CVS, as opposed to maintaining another bcbboost_1_32?

The opportunity of combining effort spent on supporting different compilers and on bug fixing. Not scattering Boost expertise across different, unrelated projects. Reaching more interested developers.

I doubt we are going to see another patched release of Boost 1.32 at this point, the regression testing cost alone is likely prohibitive.

You're probably right. On the other hand it would probably be even harder to come up with separate facilities that cater for different teams working separately. The way I see it the most concrete opportunity for open source's commercial success is companies with different goals deciding to share costs they would all face separately. When this doesn't happen it just means that there's not enough interest. Too bad for those that really were interested, but that's life. However I think it would be a pity if this were made impossible artificially.

By maintaining a separate BCBboost aimed purely at BCB customers, and QAing against BCB6 and 2006 only, it is easier to perform necessary testing and get it back into the hands of Borland customers.

You could also integrate Spirit 1.6 as the default version of the library at that point too.

Maybe. On the other hand are we sure that there's nobody out there who'd like to be able to move forward a couple of Boost releases but can't due to having to use an obsolete compiler? Cheers, Nicola Musatti

Roland Schwarz wrote:

While I think deprecation announcement is useful in general, current practice possibly is too restricting. What I would rather like too see is a library component specific deprecation.

Why should e.g. support for threading lib for an old compiler where it was known good be deprecated? In my opinion the respective library maintainer should be in charge of warning the user that the library is evolving into a direction where support of a specific compiler will be dropped in a future release. Doing this at a global scope does not allow this.

What do you think?

See Russel's comments elsewhere in this thread. The problem is that once support for any library is removed, it is harder to move forward to another Boost release even if all the other libraries you use are still supported. There are a couple of precedents for this already. Spirit dropped support for 'legacy' compilers a while back. However, a branch of the older version of the library is maintained (1.6, vs 1.8) and still tested against boost releases. Support is still available, but separately from the Spirit project, rather than through Boost itself. Robert Ramey shows how this support can be integrated as he relies on Spirit support in the Serialization library. uBlas made a similar choice to stop supporting inadequate compilers around 1.32 release. This is enforced with a #error, and there is no workaround. Generally, users of those platforms are left with a choice of dropping their use of the library, or no longer upgrading boost. And that problem gets worse when compiler vendors release upgrades that are still not supported! You are left with the choice where upgrading your compiler means losing Boost support. At the moment this would only seem to affect the Borland community, as the other compilers being dropped are long replaced by better supported compilers. Borland are still working on a compiler that has more bugs than library maintainers are comfortable supporting. Given the limitted volunteer resources that make up a FOSS project like Boost, I am trying to find the best balance for all involved - library authors, users of older compilers, and users of new compilers who don't see the benefit of all that legacy support. [Simply telling people working with old compilers they are idiots and should upgrade is not very helpful - there are MANY reasons people get stuck with tools they would rather replace, often the decision is not their's to make] Deprecating a platform boost-wide, rather than on a per-library basis, seems the best balance to me. I know which Boost version is stable and tested, I can rely on most libraries in that version, and library authors understand what is expected (but not required) of them. The all important recovery-action for the user is simple - install the version of Boost pointed at by the deprecation message. So far Boost has been a remarkably supportive community, especially the library maintainers who agreed to one more release to allow a deprecation warning. I think it is equally important we (legacy users) help them find ways to move on as well. [Clearly there is no issue for new libraries choosing not to support legacy compilers, the problem is in dropping existing support] -- AlisdairM

Nicola Musatti <Nicola.Musatti@gmail.com> writes:

...

Deprecating a platform boost-wide, rather than on a per-library basis, seems the best balance to me. I know which Boost version is stable and tested, I can rely on most libraries in that version, and library authors understand what is expected (but not required) of them. The all important recovery-action for the user is simple - install the version of Boost pointed at by the deprecation message.

I don't agree. This would work if all the library authors supported the same set of compilers. As this is not the case there is no single version of Boost that the deprecation message can reasonably refer to.

The real solution for this problem is something that Boost will have to face sooner or later and that is breaking the distribution into a set of more manageable elements.

No, really, the solution is for Borland to fix their compiler, or for market pressure to drive everyone to drop it. Let's keep things in perspective. -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:

Nicola Musatti <Nicola.Musatti@gmail.com> writes: [...]

...

The real solution for this problem is something that Boost will have to face sooner or later and that is breaking the distribution into a set of more manageable elements.

No, really, the solution is for Borland to fix their compiler, or for market pressure to drive everyone to drop it. Let's keep things in perspective.

Yes and no. It is true that had Borland kept the other vendors' pace we wouldn't be discussing this issue at all; on the other hand I'm convinced that my reasoning applies to al those that are stuck with older versions of currently compliant compilers. Again, it all boils down to actual numbers and available volunteers. The fact that it isn't happening is a clear indication of how things stand :-) As to the other reasons why modularization would be desirable (and the problems it would entail!) it's a topic that deserves a thread of its own, but I'm not going to start it. Cheers, Nicola Musatti