On 01/13/2014 05:38 PM, David Nadlinger wrote:
On Mon, Jan 13, 2014 at 7:10 AM, Brad Anderson <[email protected]> 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.
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
