Re: [boost] Removing support for old compilers

Subject: Re: [boost] Removing support for old compilers
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2013-10-13 06:11:04

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]

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.

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])
* 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.)
* 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. 

Joaquín M López Muñoz
Telefónica Digital