[dmd-beta] Preparation for 2.65

[Martin Nowak]

On 01/13/2014 05:38 PM, David Nadlinger wrote:
> On Mon, Jan 13, 2014 at 7:10 AM, Brad Anderson <eco at gnuk.net> wrote:
>> http://wiki.dlang.org/Simplified_Release_Process_Proposal
> Even though I'm not sure whether this proposal is the best choice, let
> me point out that it gets one point very right, compared to the
> current state: After a release is created, the branch needs to be
> merged back into master. Otherwise, people just tracking the release
> tags (like we tend to do for the ldc druntime/Phobos repositories)
> will usually get a slew of conflicts due to commits cherry-picked onto
> the release branch or conflicting release-only changes.
I don't understand the last argument. What's your workflow for updating 
LDC's druntime and phobos?
How does merging back release branches help here?
>
> Doing this at the point of the release has the advantage that the
> release manager is the one who knows what went where for what reasons,
> and that they still have all the details in their working memory.
>
> I suspect that liberal use of cherry-picking will make this process a
> bit more annoying than necessary, but it could be that the
> simplification of the process indeed outweighs this extra bit of
> effort.
I think this "extra bit" of effort will make this process unsuitable.
If you cherry-pick from master onto a release branch you already have to 
resolve conflicts sometimes.
Now when you merge the release branch back into master the resulting 
merge conflict is non-trivial.
Difficult merges are usually best resolved by the people who made the 
code changes.