Re: [boost] Coordinating Boost Releases with compiler releases

Subject: Re: [boost] Coordinating Boost Releases with compiler releases
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-03-14 15:07:54

On 3/14/19 5:53 PM, Marshall Clow via Boost 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.

I agree with you, compiler (or other software) releases are not the 
reason to shift Boost releases. I can add a few reasons to those you 
have listed:

* If the new compiler is not immediately compatibe with the current 
Boost, there needs to be a potentially significant lag for Boost 
libraries to be updated. Which might be equivalent lagging one Boost 
release with out current schedule. If the compiler doesn't break Boost 
then the problem is non-existent in the first place.

* There may also be downstream Boost users who depend on the current 
schedule.