Re: updating the release process; what to do about branches

[Steve Loughran <st...@hortonworks.com>]

Following up now that I am in track of emails again.

Assuming we stay with develop/ for development stuff, how about we just rm the master/ branch,

then switch to having separate branches for branches being released/updated, tags on the branches for released and latest.

The release process would cover this, with something that can even cover the "branch off develop and cherry-pick" strategy if that is what people want to do when stabilising a release

-steve



On 29 January 2015 at 16:38:48, Jon Maron (jmaron@hortonworks.com<ma...@hortonworks.com>) wrote:

I would favor the current mapping - a little more intuitive IMHO

On Jan 29, 2015, at 5:40 AM, Steve Loughran <st...@hortonworks.com> wrote:

>
> (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 <jo...@gmail.com>
> Sent: 28 January 2015 18:02
> To: dev@slider.incubator.apache.org
> 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<st...@hortonworks.com>
>> 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.
>>>
>>
>>
>>

Re: updating the release process; what to do about branches

[Sumit Mohanty <sm...@hortonworks.com>]

+1.
________________________________________
From: Steve Loughran <st...@hortonworks.com>
Sent: Monday, February 02, 2015 4:26 AM
To: dev@slider.incubator.apache.org
Subject: Re: updating the release process; what to do about branches

Following up now that I am in track of emails again.

Assuming we stay with develop/ for development stuff, how about we just rm the master/ branch,

then switch to having separate branches for branches being released/updated, tags on the branches for released and latest.

The release process would cover this, with something that can even cover the "branch off develop and cherry-pick" strategy if that is what people want to do when stabilising a release

-steve



On 29 January 2015 at 16:38:48, Jon Maron (jmaron@hortonworks.com<ma...@hortonworks.com>) wrote:

I would favor the current mapping - a little more intuitive IMHO

On Jan 29, 2015, at 5:40 AM, Steve Loughran <st...@hortonworks.com> wrote:

>
> (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 <jo...@gmail.com>
> Sent: 28 January 2015 18:02
> To: dev@slider.incubator.apache.org
> 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<st...@hortonworks.com>
>> 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://cp.mcafee.com/d/avndzgQ76Qm4QTDHTKCrKrhKUZtZxBBwSztMQsIecEEFCQrKfnvoppvdETsd7bWbaqoUThmFfojb0EDmcWMclylFOVIDmcWMclylFOVJ6W3zJC7-LP0UQsCzBV_HTbFIIIYYC_tC_bnjIyyGztfBgY-F6lK1FJ4SyrLOtXTLuZXTdTdw0W7Og-fixpIxIWNXlJIj_w0e8upY-GQE4szV_Xik2f0USxVAL7VJNwnsopsbQlGjS4ONNeIpRwoH4HjBMlg-i7NWkbdAdDmfqJJyvY01dCzBV5MS2_id43qO6PB0yq89A_d44vf_quq85ERJZa0wQg62uPd44WCy12FEwQxlKpEw8hS5yvQdLCzATIGTiXEs
>>>
>>> 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.
>>>
>>
>>
>>