Re: [boost] Coordinating Boost Releases with compiler releases

Subject: Re: [boost] Coordinating Boost Releases with compiler releases
From: Tom Kent (lists_at_[hidden])
Date: 2019-03-14 21:42:43

On Thu, Mar 14, 2019 at 9:53 AM Marshall Clow via Boost <
boost_at_[hidden]> wrote:

> In the thread "MSVC 2019 and 1.70 beta", there has been a discussion about
> what to do about support for MSVC 2019, which is due to be released right
> about the same time that Boost 1.70.  One person suggested that we delay
> the boost release until after the MSVC release (I think the suggestion was
> "May").
>
> This general question has been discussed before (several times), since
> tools get released fairly often - and so does Boost.
>
> In general, I am not in favor of delaying boost releases in order to add
> support for 'about to be released' development tools.  There are two main
> reasons for this:
>
> * There's always another compiler / tool about to be released.   Clang 8 is
> imminent - currently at RC5.  GCC 9.1 is scheduled to be released in early
> May.
>
> * Boost releases happen every four months. August is not really that far
> off. People who want support for tool XXXX can use "the trunk", getting it
> either from git or from bintray.
> [ Everyone knows about the tarballs at bintray, right?
> https://dl.bintray.com/boostorg/master/ ]
>
> Also, if we were to delay the boost release until May, then what would
> happen to the August release?  The release process for 1.71.0 is scheduled
> to start at the end of June.
>
> -- Marshall
>

I don't believe that we should hold up the build to wait for VS2019 to
ship. However, I do believe that we should merge in (existing) support to
enable VS2019 before the release. Clang/GCC are different, because they
don't require any changes to the codebase to enable new versions.

Clang 8 is already building in the regression test matrix against both
master and develop.

VS2019 is building in the regression test matrix against develop. I have a
job that is attempting to build it against master, but it fails so early in
the process that it doesn't upload anything, and we don't see an all yellow
column.

The risk (minor?) here is that merging support to master will cause
failures (that aren't in develop?). When users run and see that VS2019 is
building, they will assume full support (i.e. that authors have had a
chance to checkout their library), which it won't have.

Lets merge to master and *not* list this as a supported compiler.

Tom