Re: [boost] Boost 1.61.0 Release Candidate 1

Subject: Re: [boost] Boost 1.61.0 Release Candidate 1
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-05-03 10:56:24

On 5/3/16 12:46 AM, Vladimir Prus wrote:
> On 02.05.2016 11:07, Murray Cumming wrote:
>> On Do, 2016-04-28 at 00:37 +0300, Vladimir Prus wrote:
>>> The release candidates for the 1.61.0 release are now available at:
>>>
>>>      http://boost.cowic.de/rc/boost_1_61_0_rc1.zip
>>>      http://boost.cowic.de/rc/boost_1_61_0_rc1.7z
>>>      http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.bz2
>>>      http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.gz
>> [snip]
>>
>> Thanks.
>>
>> This is a very minor issue, but I noticed that the boost graph examples
>> are missing a little fix that has been in develop (but not master)
>> since before 1.60 but it didn't get into 1.60 or this 1.61 release
>> candidate:
>> https://github.com/boostorg/graph/commit/63dd92da7247018f3291d48cfe04a5
>> 7e51b48eb0
>>
>> Isn't example code built as part of a release?
>
> Murray,
>
> I see that Noel has said he'd sync graph after the release, which should
> fix
> your immediate concern.
>
> As for examples, no, they are not automatically built at present. This
> is something
> that would be good to change, but for 1.62 in the best case.
>

I'm sure somewhere we have a "tool", git command, script or whatever 
which can create a report which shows which libraries have differences 
between develop and master branches in a concise way.  So maybe the 
release procedure should start with a generation and display of this 
report followed by nagging of developers to get them in sync. Once 
they're in sync, developers would be admonished not to check into 
develop until the master is checked.  One great thing about git is that 
it lets me easily create a temporary local branch in which I can store 
my local changes then merge them into develop as soon as the release 
ships.  To summarize:

a) announce intention to ship master
b) encourage developers to sync develop to master
c) prepare summary report of differences
d) review tests on master branch, ship beta, etc.  cycle until done.
e) ship release, open master and develop for changes.

we want to maintain the distinction between master and develop.  But 
during a hopefully short time, they should be in sync.

Robert Ramey