(apologies for any formatting confusion here; I am migrating to Outlook web
apps)
I quite like the git flow bit of the sourcetree GUI; it looks like we can
change the policy here for it to make the "master" branch the one git flow
branches from/merges with, "master" could be "release" -and ignored if we don't
use that aspect of the git flow process
[gitflow "branch"]
master = master
develop = develop
________________________________________
From: Josh Elser <[email protected]>
Sent: 28 January 2015 18:02
To: [email protected]
Subject: Re: updating the release process; what to do about branches
Could also just remove "master" in its current use and
s/develop/master/, leveraging the master branch as the normal place
things are implemented.
It really doesn't matter in the end (it's just a name), but, if this is
also signifying a move away from git-flow, it makes more sense to me to
use "master" instead of "develop".
Sumit Mohanty wrote:
> I vote for removing the master branch. This is in the line of what I was
> also wondering since we have created branches for 0.60 and 0.70. Branches
> can remain the source of truth for the release and can facilitate minor
> releases if needed.
>
> On Wed, Jan 28, 2015 at 8:58 AM, Steve Loughran<[email protected]>
> wrote:
>
>> The latest release process document is now in svn at
>> site/trunk/content/developing/releasing.md
>>
>> It hasn't yet propagated to the HTML view, when it does it will be at
>>
>> http://slider.incubator.apache.org/developing/releasing.html
>>
>> I think we've outgrown the git flow release process.
>>
>> The feature branch seems to work well, but the release process has
>> everything merged into the branch "master",
>>
>> - It doesn't handle long-lived release/supported branches
>> - Merging into master/ can create convoluted dependency graphs,
>> resulting a commit graph (and hence git commit ID) which is different
>> from
>> what is released.
>>
>> What are we to do?
>>
>> I'm wondering if we should get rid of that master/ branch altogether.
>>
>> Instead we could have some tags which we could move around:
>>
>> - last_branch_6_stable_release
>> - last_branch_6_dev_release
>> - last_branch_7_stable_release
>> - last_branch_7_dev_release
>> - last_stable_release
>> - last_dev_release
>>
>> If you fetch all tags then check out by tag, you end with whatever version
>> we think is "last" on a branch; the stable/dev releases can even cross
>> branches as something migrates from development to stable
>>
>> During the release process, instead of doing git merge master work, we'd
>> just delete some tags, create the new ones and then push them to the
>> origin.
>>
>> Thoughts?
>>
>> -steve
>>
>> --
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity to
>> which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>>
>
>
>
