Re: [boost] Removing support for old compilers

Subject: Re: [boost] Removing support for old compilers
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-10-13 06:53:30

Le 13/10/13 12:11, Joaquin M Lopez Munoz a écrit :
> Stephen Kelly <steveire <at> gmail.com> writes:
>
>> On 10/12/2013 10:13 PM, Joaquin M Lopez Munoz wrote:
>>> Hi Stephen
>>>
>>> As part of your initiative of removing support for old compilers,
>>> are you building somewhere a change log in the form of either a list
>>> of compiler deficiencies or compiler versions no longer supported?
>> I have not built such a thing, but it's easy to create by reading the
>> recent log of boost/config.
> Not obvious to me: the message log for your changes at boost/config
> reads
>
> * Remove remaining occurances of BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
>    These evaded scripting.
> * Require compiler support for partial template specialization.
>    Remove support for the mac programmers workshop entirely. Bump
>    the sunpro requirement to version 5.4. Version 5.3 seems to have
>    had some bugs with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, so
>    bump above that in the abundance of caution.
>    This allows the removal of lots of workaround code:
>
>      src/boost-trunk{master}$ ../kf5/remove_def.py
>      BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
>      src/boost-trunk{master}$ git diff --shortstat
>       192 files changed, 4798 deletions(-)
> * Remove obsolete MSVC check from pragma guard
>    git grep -h -B1 "^#\s*pragma once" | grep -v pragma | sort | uniq
>    is now clean.
> * Config: Remove obsolete MSVC version check
>
> Frankly, it is hard to know what's going on by looking at this
> log alone. In particular, nowhere's stated which versions of
> MSVC have been dropped (I understand 6.0 and 7.0, but the log
> does not say it), and one has to investigate in order to find out
> what other compilers are effecively dropped as a consequence of TPS
> being required (the log mentions MPW and SunPro 5.3, but I guess
> Digital Mars and GCC 2.x are also affected, don't know about
> Borland, and maybe there are others as well). I have also the suspicion
> that along the way you have removed macros and workarounds not
> directly related to TPS or MSVC 6.0/7.0.
>
>> Where should it be and what should it say?
> As for the form of the doc, something like this would be IMHO fine:
>
> * New minimal requirements on compilers/environments suported by
> Boost 1.56
>    - Template partial specialization support
>      · Deleted BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION and [etc]
>      from Boost.Config
>    - [Additional new requirements, SFINAE for instance]
>      · [Resulting changes in Boost.Config (macros removed and so on)]
> * Compilers dropped starting in Boost 1.56
>    - MSVC 7.0 and prior
>      · [Boost.Config facilities removed as a consequencce]
>    - GCC 2.x
>      · [Boost.Config facilities removed as a consequencce]
>    - [etc]
> * List of Boost libs directly modified [useful as a heads up for
> maintainers wishing to review your changes]
+1
> As for where to put it, the final destination would be
>
> https://svn.boost.org/svn/boost/website/public_html/live/feed/history/
> file boost_1_56_0.qbk
>
> although this file has not been created yet. You can either ask
> for the file to be created or, in the meantime, publish your log
> somewhere for easy reference and public access.
+1
> Some other things that'd help:
>
> * Consider adding some [xxx] subject tag in your communications to
> the mailing list so that users and maintainers can easily track
> them (for instance, [compiler support])
+1. I think that every changes set should contain [library] text
> * Allow for some time for people to express support/dissent on proposed
> removals before going ahead, and notify the list when a change is
> effective. It is important that a proposed change comes with a list
> of compilers affected (users don't necessarily know whether some
> compiler X they care about does support, say, TPS, so we need to
> make sure this is clear to everybody potentially affected.)
+1. Authors and maintainer should be notified before commit.
> * With all due respect, I think you are being a little too aggresive
> at executing this. Removal of compiler support is a sensitive issue
> and sure enough we won't get unanimous consensus, but some form of
> general agreement should be reached, and time be given for awareness
> and discussion. That said, some assertiveness will be needed at the
> end of the day: it's a matter of finding the right balance and not
> going overboard with changes that could potentially harm existing
> Boost users.
>
>
+1. These kind of changes could seem simple but the possibility to break 
existing code is high.

Best,
Vicente