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 13:35:22

On 5/3/16 10:22 AM, Vicente J. Botet Escriba wrote:
> Le 03/05/2016 16:56, Robert Ramey a écrit :
>>
>>>
>>
>> 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.
>>
> When I have to fix a bug I need to commit in develop so that I can check
> if this is a fix and if there is no regressions.

I'm aware of this and I don't think my proposal conflicts with this.

what I want to see is that we avoid the last minute hangups which make 
for more work.  So my proposal would restrict to develop commits to just 
those which support the release.

But maybe there's a better way.  Here's a different and maybe better idea.

a) generate report of differences between develop and master
b) nag authors to get stuff in sync.
c) verify status of master tests.
d) if there's a couple of last minute changes there would two
options:
1) go through develop and merge to master
2) merge to master directly and just watch the master tests.
e) send out master beta (note two words!)
f) after the thing ships - merge master back into develop for those 
libraries with last minute changes.

maybe there's an even better way.

a) generate report of differences between develop and master
b) nag authors to get stuff in sync.
c) verify status of master tests.
d) create a NEW branch - beta 1.162 from the current master
e) put "last minute" changes in to this new branch.
f) test the beta - hmmm best way to do this.
g) after shipment, authors would be responsable for merging from beta 
back develop.

Actually, I like this last scheme a lot.  It seems in line with the way 
git is meant to be used.  I've used local branching to very good effect 
and it's very fast and efficient.  The only rub is the beta testing 
matrix - I'm not sure how that would be implemented.

The whole point of all this is make life less taxing for the release 
managers.  So I don't want to make any major change.  I'm just hoping we 
can use our existing tools to better effect.

Robert Ramey

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