Re: [boost] [Removing support for old compilers]

Subject: Re: [boost] [Removing support for old compilers]
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-10-14 12:57:17

On Mon, Oct 14, 2013 at 9:40 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Andrey Semashev wrote:
>>> d) maintainers of boost libraries.  When I first raised this
>>> question, I was assured that it would be totally transparent
>>> to me and that I would not have to be concerned about it.
>>> Hmmm - well  OK - as long I don't have to wade in and
>>> muck around with ten year old code - (don't even think about
>>> addressing any changes which make old data sets unreadable).
>>> My worst nightmare is having to go back and re-debug
>>> 20 thousand lines of code running on 10 different compilers.
>>> Recent postings have made me doubt that one can really
>>> undertake this and guarentee that I won't have to do this.
>>
>> I didn't really understand your point here. Do you intend to support
>> the old compilers, even if Boost in general drops them?
>
> I don't intend to specifically support old compilers - I don't intend
> to drop support for them either as it's already in there.

These are exclusive statements. Unless you regularly test your library
on old compilers, the library can already be not working with them.
This may be due to some fix/improvement/feature in the library, or to
some change in a dependent library. Note that the compilers we're
dropping are not tested by any of the testers, so you would have to
run the tests yourself.

> Actually
> I don't intend to do any work on the serialization library that doesn't
> add functionality.  It looks like that if this goes through, I'll have to
> to go back and re-debug the library to support a decrease of
> functionallity - not something I can justify the investment of time
> in - not to say that's it's no fun at all.

Sorry, but I still don't understand. No one is removing any
functionality, only the workarounds needed to make the library work on
some broken compiler. Why would you need to spend time ensuring that
the library no longer works on that compiler when the workarounds are
removed?

>> My understanding is that the most immediate benefit is exactly for
>> Boost library maintainers. Dropping support for ancient compilers
>> simplifies code (Boost.Config included), makes it more easily
>> maintainable.
>
> on NEW libraries - but it has the potential of creating huge amount
> of unpleasant work for older libraries. - with not net benefit to
> anyone.

I was specifically referring to the current (and more likely, older)
libraries in Boost, not the new ones. It is implied that the new
libraries have no such issue.