Re: [boost] Candidate for 1.66.1, if there is one

Subject: Re: [boost] Candidate for 1.66.1, if there is one
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-12-23 16:25:24

On 12/23/17 7:58 AM, James E. King, III via Boost wrote:
> In Boost 1.66.0, there was a fix to date_time for the year 2038 problem:
> 
> https://github.com/boostorg/date_time/pull/35

<snip>

Personally, I think any efforts to making a point release would be 
better spent on the next release.  In other words I don't think this 
should be done.

What think is better would be:

a) make changes in the develop branch as soon as is convenient
b) watch the test matrix and results from the CI implementations
c) when one is satisfied with these results - merge to master

If someone has an urgent need to included these lastest fixes, he can 
merge the lastest master to his local system before the next release. 
Of course he should run the test suite on this new version of the maser 
on his local system.

As boost gets bigger, managing a boost release where everything is 
"perfect" cannot scale.  Thus we are seeing that the difficulty of 
making such a release is increasing over time.

I believe that a better goal would be to "Allow users to have a perfect 
implementation of the libraries they use" on their own schedule.  I 
think this is more realistic, practical, timely for users and easier for 
maintainers.  I recognize that it's a radical change:

a) It effectively decouples boost libraries from each other - some more 
than others.
b) It places more responsibility on users to test those libraries they 
use on the systems they use them on.
c) b) above requires infrastructure such as procedures, utilities and 
practices that are either not defined, or not documented.

But not moving in this direction is hold us back.

> I'm looking at adding a test to
> write out a version 0 and then read it in when the current version is 1,
> but I don't want to add test-only support code to the headers that get
> shipped, so if anyone can point me at a current example unit test that
> writes out a "n-1" version and then reads in a "n" version with
> boost::serialization I would appreciate it.

This is something which would be very useful and has always been desired.

a) It would be quite a bit of work to implement such a series of tests
b) and describe how to set it up
c) The serialization library already places a lot of burden on the 
testing infrastructure.  This would increases that load significantly.

Robert Ramey

> 
> Thanks,
> 
> Jim
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>