You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anthony Baker <ab...@pivotal.io> on 2015/05/01 15:53:57 UTC
Branching model
I suggest we adopt the gitflow model for branching as described in [1] and [2]. Following an established and consistent pattern for branching makes it easier for new users and devs to contribute.
Here are the main gitflow concepts:
1) The master branch is reserved for production-ready code, aka releases. No changes are made directly on the master branch.
2) The develop branch is the development mainline. Ongoing work shows up here first.
3) Feature branches may be used to isolate interim work and will merge back to develop.
4) Release branches are created to allow a stabilization period for a release while not impacting ongoing work on develop. Once a release is stabilized the release branch is merged to master and develop.
5) Maintenance branches are created after a release (off master) to support ongoing hot fixes and patches as needed. This diverges slightly from the “hotfix” model in the original gitlfow idea but works better for releases with a longer life span.
Branch naming:
- master
- develop
- release/vVERSION
- maint/vVERSION
where VERSION is semantic version name [3].
Actions needed:
1) Create the develop branch off of master.
2) Run nightly builds from the develop branch.
3) Set the default branch for the repo to develop (is this possible with the ASF git repo?).
4) Create a wiki page to codify the model and naming conventions.
Thoughts?
Anthony
[1] http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/>
[2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow>
[3] http://semver.org <http://semver.org/>
Re: Branching model
Posted by Anthony Baker <ab...@pivotal.io>.
Thanks for commenting jan. To me the value of the release branch is allowing uninterrupted ongoing work on the develop branch while isolating the work to stabilize the code in preparation for a release. I would hesitate to merge directly from develop to master until we had proven stability which usually requires a settling out period. But like you say this is a philosophical thing and I am fine with which ever approach we decide upon.
Anthony
> On May 1, 2015, at 7:07 AM, jan i <ja...@apache.org> wrote:
>
> On 1 May 2015 at 15:53, Anthony Baker <ab...@pivotal.io> wrote:
>
>> I suggest we adopt the gitflow model for branching as described in [1] and
>> [2]. Following an established and consistent pattern for branching makes
>> it easier for new users and devs to contribute.
>>
>> Here are the main gitflow concepts:
>>
>> 1) The master branch is reserved for production-ready code, aka releases.
>> No changes are made directly on the master branch.
>>
> I would make an even tighter definition here.
>
> Master is merged solely from develop, and only by the "release manager".
> Merges can only be done, when build is successful on all supported
> platforms, and
> the tests on all supported platforms have passed.
>
>>
>> 2) The develop branch is the development mainline. Ongoing work shows up
>> here first.
>>
> +1
>
>>
>> 3) Feature branches may be used to isolate interim work and will merge
>> back to develop.
>>
> Public feature branches should only be used, when multiple people work on a
> feature. A feature branch is started after the intention is made clear on
> dev@
>
>
>>
>> 4) Release branches are created to allow a stabilization period for a
>> release while not impacting ongoing work on develop. Once a release is
>> stabilized the release branch is merged to master and develop.
>>
> This is the purpose of master, I would not make extra release branches,
> however this is close to being religious. If release branches are made they
> should solely relate to master, NOT to develop.
>
> Instead of a branch, which is a lot of overhead, I would just use the GIT
> id of master, to identify the original release.
>
>
>>
>> 5) Maintenance branches are created after a release (off master) to
>> support ongoing hot fixes and patches as needed. This diverges slightly
>> from the “hotfix” model in the original gitlfow idea but works better for
>> releases with a longer life span.
>>
> +1, but it should be avoided, to keep the logistic (non-productive) work
> volume low, try to avoid making a hotfix for older releases.
>
>
>> Branch naming:
>> - master
>> - develop
>> - release/vVERSION
>> - maint/vVERSION
>>
>> where VERSION is semantic version name [3].
>>
>> Actions needed:
>>
>> 1) Create the develop branch off of master.
>> 2) Run nightly builds from the develop branch.
>>
> and e.g. weekly builds on master. Alternatively, whenever master is updated
> run a build.
>
> 3) Set the default branch for the repo to develop (is this possible with
>> the ASF git repo?).
>>
> yes
>
>> 4) Create a wiki page to codify the model and naming conventions.
>>
> +1
>
>>
>> Thoughts?
>>
> Please see my thought, not as an active developer, but as a mentor with
> experience from other projects.
>
>
>>
>> Anthony
>>
> nice suggestion.
>
> rgds
> jan i.
>
>>
>>
>> [1] http://nvie.com/posts/a-successful-git-branching-model/ <
>> http://nvie.com/posts/a-successful-git-branching-model/>
>> [2]
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>> <
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>>>
>> [3] http://semver.org <http://semver.org/>
>>
>>
Re: Branching model
Posted by Lyndon Adams <ly...@gmail.com>.
+1
Sent from my iPhone
> On 6 May 2015, at 10:58, Pid <pi...@pidster.com> wrote:
>
>> On 01/05/2015 17:50, Dan Smith wrote:
>>> On Fri, May 1, 2015 at 7:07 AM, jan i <ja...@apache.org> wrote:
>>>
>>> Public feature branches should only be used, when multiple people work on a
>>> feature. A feature branch is started after the intention is made clear on
>>> dev@
>
> Pushing a feature branch could be a simple way to offer it for review.
>
> I understand that Geode will be RTC (Review-Then-Commit), so we should
> discuss how the review process will work in combination with git-flow.
>
>
>> One thing we've done within our organization is make a distinction between
>> public feature branches - which are longer lived with multiple committers,
>> and "work in progress" branches for individual changes which are generally
>> owned by a single committer and are very short lived.
>>
>> Would it make sense for committers to create work in progress branches on
>> the apache github, or should these be maintained outside apache
>> infastructure?
>
> As above, I think the mechanism by which proposed changes are to be
> reviewed has some bearing here.
>
>
> IMHO it doesn't make sense to maintain branches elsewhere, unless they
> are solely in your local copy of the git repository and there's some
> other mechanism for reviewing them before they are merged into the
> develop branch on the origin repo.
>
>
> Thoughts?
>
>
> p
>
>
>
>> -Dan
>
>
> --
>
> [key:62590808]
Re: Branching model
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, May 06, 2015 at 06:47AM, Justin Erenkrantz wrote:
> On Wed, May 6, 2015 at 5:07 AM, <da...@simplicityitself.com> wrote:
> > I would suggest having most work in the github world, and a published
> > method for new contributors to do a normal github fork and pull approach.
> > Contributors can then use a process to migrate that to apache git once it
> > is approved for merge. That allows use of the github infra for review and
> > a public face where, at the moment, people would expect it to be.
>
> I would strongly advise against that.
>
> All of the discussion should happen on the ASF mailing lists or other
> infrastructure-supported tools.
>
> We should not be having discussions solely within the GitHub
> infrastructure. One of the key lockins is that GitHub does not
> support exporting those comments on a PR - so, when GitHub disappears
> (which it will eventually), all of that information will be lost.
>
> If Geode simply wanted to be a GitHub project, it didn't need to come to Apache.
>
> My $.02. -- justin
Absolutely. Source of the data - code, mail-list, docs - should originate from
the ASF infrastructure. I am happy to provide some links to the discussions
where this point has been explained at lengths on Ignite dev@ list.
Cos
Re: Branching model
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, May 6, 2015 at 3:47 AM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Wed, May 6, 2015 at 5:07 AM, <da...@simplicityitself.com> wrote:
>> I would suggest having most work in the github world, and a published method for
>> new contributors to do a normal github fork and pull approach. Contributors can then
>> use a process to migrate that to apache git once it is approved for merge. That allows
>> use of the github infra for review and a public face where, at the moment, people would expect it to be.
>
> I would strongly advise against that.
Very strong +1 to that. See the other thread where I'm proposing
JIRA to be the single source of truth for the project.
> All of the discussion should happen on the ASF mailing lists or other
> infrastructure-supported tools.
>
> We should not be having discussions solely within the GitHub
> infrastructure. One of the key lockins is that GitHub does not
> support exporting those comments on a PR - so, when GitHub disappears
> (which it will eventually), all of that information will be lost.
Now, I think using Github as one of the review tools and accepting
PRs is actually fine. Typically the discussion between reviewers
is captured on JIRA. But! Given our GH integration the discussion
between reviewers is actually captured on the mailing list. Which,
in my opinion is as good (if not better -- think searching) as JIRA.
Thoughts?
Thanks,
Roman.
Re: Branching model
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 6, 2015 at 5:07 AM, <da...@simplicityitself.com> wrote:
> I would suggest having most work in the github world, and a published method for new contributors to do a normal github fork and pull approach. Contributors can then use a process to migrate that to apache git once it is approved for merge. That allows use of the github infra for review and a public face where, at the moment, people would expect it to be.
I would strongly advise against that.
All of the discussion should happen on the ASF mailing lists or other
infrastructure-supported tools.
We should not be having discussions solely within the GitHub
infrastructure. One of the key lockins is that GitHub does not
support exporting those comments on a PR - so, when GitHub disappears
(which it will eventually), all of that information will be lost.
If Geode simply wanted to be a GitHub project, it didn't need to come to Apache.
My $.02. -- justin
Re: Branching model
Posted by da...@simplicityitself.com.
There is a very similar discussion ongoing on the groovy incubation mailing list.
The rub is that for commits to be accepted into geode, they have to be pushed to the apache git repo. This removes the option of using github pull requests as a way of following through the whole code acceptance flow.
It does though mean that you can create forks of the github mirror, open a PR and then locally merge that onto the apache git as another git remote alongside github.
I would suggest having most work in the github world, and a published method for new contributors to do a normal github fork and pull approach. Contributors can then use a process to migrate that to apache git once it is approved for merge. That allows use of the github infra for review and a public face where, at the moment, people would expect it to be.
This is something of a seperate thing from the branching model, sorry for hijacking the thread.
David.
--
David Dawson
CEO
Simplicity Itself Ltd
Tel +7866011256
Skype davidadawson
david.dawson@simplicityitself.com
http://www.simplicityitself.com
Original Message
From: Pid
Sent: Wednesday, 6 May 2015 09:59
To: dev@geode.incubator.apache.org
Reply To: dev@geode.incubator.apache.org
Subject: Re: Branching model
On 01/05/2015 17:50, Dan Smith wrote:
> On Fri, May 1, 2015 at 7:07 AM, jan i <ja...@apache.org> wrote:
>
>> Public feature branches should only be used, when multiple people work on a
>> feature. A feature branch is started after the intention is made clear on
>> dev@
Pushing a feature branch could be a simple way to offer it for review.
I understand that Geode will be RTC (Review-Then-Commit), so we should
discuss how the review process will work in combination with git-flow.
> One thing we've done within our organization is make a distinction between
> public feature branches - which are longer lived with multiple committers,
> and "work in progress" branches for individual changes which are generally
> owned by a single committer and are very short lived.
>
> Would it make sense for committers to create work in progress branches on
> the apache github, or should these be maintained outside apache
> infastructure?
As above, I think the mechanism by which proposed changes are to be
reviewed has some bearing here.
IMHO it doesn't make sense to maintain branches elsewhere, unless they
are solely in your local copy of the git repository and there's some
other mechanism for reviewing them before they are merged into the
develop branch on the origin repo.
Thoughts?
p
> -Dan
>
--
[key:62590808]
Re: Branching model
Posted by Pid <pi...@pidster.com>.
On 01/05/2015 17:50, Dan Smith wrote:
> On Fri, May 1, 2015 at 7:07 AM, jan i <ja...@apache.org> wrote:
>
>> Public feature branches should only be used, when multiple people work on a
>> feature. A feature branch is started after the intention is made clear on
>> dev@
Pushing a feature branch could be a simple way to offer it for review.
I understand that Geode will be RTC (Review-Then-Commit), so we should
discuss how the review process will work in combination with git-flow.
> One thing we've done within our organization is make a distinction between
> public feature branches - which are longer lived with multiple committers,
> and "work in progress" branches for individual changes which are generally
> owned by a single committer and are very short lived.
>
> Would it make sense for committers to create work in progress branches on
> the apache github, or should these be maintained outside apache
> infastructure?
As above, I think the mechanism by which proposed changes are to be
reviewed has some bearing here.
IMHO it doesn't make sense to maintain branches elsewhere, unless they
are solely in your local copy of the git repository and there's some
other mechanism for reviewing them before they are merged into the
develop branch on the origin repo.
Thoughts?
p
> -Dan
>
--
[key:62590808]
Re: Branching model
Posted by Dan Smith <ds...@pivotal.io>.
On Fri, May 1, 2015 at 7:07 AM, jan i <ja...@apache.org> wrote:
> Public feature branches should only be used, when multiple people work on a
> feature. A feature branch is started after the intention is made clear on
> dev@
>
One thing we've done within our organization is make a distinction between
public feature branches - which are longer lived with multiple committers,
and "work in progress" branches for individual changes which are generally
owned by a single committer and are very short lived.
Would it make sense for committers to create work in progress branches on
the apache github, or should these be maintained outside apache
infastructure?
-Dan
Re: Branching model
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
On Fri, May 1, 2015 at 7:07 AM, jan i <ja...@apache.org> wrote:
> On 1 May 2015 at 15:53, Anthony Baker <ab...@pivotal.io> wrote:
>
> > I suggest we adopt the gitflow model for branching as described in [1]
> and
> > [2]. Following an established and consistent pattern for branching makes
> > it easier for new users and devs to contribute.
> >
> > Here are the main gitflow concepts:
> >
> > 1) The master branch is reserved for production-ready code, aka releases.
> > No changes are made directly on the master branch.
> >
> I would make an even tighter definition here.
>
> Master is merged solely from develop, and only by the "release manager".
> Merges can only be done, when build is successful on all supported
> platforms, and
> the tests on all supported platforms have passed.
>
> >
> > 2) The develop branch is the development mainline. Ongoing work shows up
> > here first.
> >
> +1
>
> >
> > 3) Feature branches may be used to isolate interim work and will merge
> > back to develop.
> >
> Public feature branches should only be used, when multiple people work on a
> feature. A feature branch is started after the intention is made clear on
> dev@
>
> I would like to propose a convention that the public feature branches have
a JIRA issue number as part of their name to make it easy to tie the branch
to the work taking place on it.
>
> >
> > 4) Release branches are created to allow a stabilization period for a
> > release while not impacting ongoing work on develop. Once a release is
> > stabilized the release branch is merged to master and develop.
> >
> This is the purpose of master, I would not make extra release branches,
> however this is close to being religious. If release branches are made they
> should solely relate to master, NOT to develop.
>
> Instead of a branch, which is a lot of overhead, I would just use the GIT
> id of master, to identify the original release.
>
>
> >
> > 5) Maintenance branches are created after a release (off master) to
> > support ongoing hot fixes and patches as needed. This diverges slightly
> > from the “hotfix” model in the original gitlfow idea but works better for
> > releases with a longer life span.
> >
> +1, but it should be avoided, to keep the logistic (non-productive) work
> volume low, try to avoid making a hotfix for older releases.
>
>
> > Branch naming:
> > - master
> > - develop
> > - release/vVERSION
> > - maint/vVERSION
> >
> > where VERSION is semantic version name [3].
> >
> > Actions needed:
> >
> > 1) Create the develop branch off of master.
> > 2) Run nightly builds from the develop branch.
> >
> and e.g. weekly builds on master. Alternatively, whenever master is updated
> run a build.
>
> 3) Set the default branch for the repo to develop (is this possible with
> > the ASF git repo?).
> >
> yes
>
> > 4) Create a wiki page to codify the model and naming conventions.
> >
> +1
>
> >
> > Thoughts?
> >
> Please see my thought, not as an active developer, but as a mentor with
> experience from other projects.
>
>
+1.
>
> >
> > Anthony
> >
> nice suggestion.
>
> rgds
> jan i.
>
> >
> >
> > [1] http://nvie.com/posts/a-successful-git-branching-model/ <
> > http://nvie.com/posts/a-successful-git-branching-model/>
> > [2]
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > <
> >
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> > >
> > [3] http://semver.org <http://semver.org/>
> >
> >
>
Re: Branching model
Posted by Pid <pi...@pidster.com>.
On 01/05/2015 15:07, jan i wrote:
> On 1 May 2015 at 15:53, Anthony Baker <ab...@pivotal.io> wrote:
>
>> I suggest we adopt the gitflow model for branching as described in [1] and
>> [2]. Following an established and consistent pattern for branching makes
>> it easier for new users and devs to contribute.
>>
>> Here are the main gitflow concepts:
>>
>> 1) The master branch is reserved for production-ready code, aka releases.
>> No changes are made directly on the master branch.
>>
> I would make an even tighter definition here.
>
> Master is merged solely from develop, and only by the "release manager".
> Merges can only be done, when build is successful on all supported
> platforms, and
> the tests on all supported platforms have passed.
>
>>
>> 2) The develop branch is the development mainline. Ongoing work shows up
>> here first.
>>
> +1
>
>>
>> 3) Feature branches may be used to isolate interim work and will merge
>> back to develop.
>>
> Public feature branches should only be used, when multiple people work on a
> feature. A feature branch is started after the intention is made clear on
> dev@
>
>
>>
>> 4) Release branches are created to allow a stabilization period for a
>> release while not impacting ongoing work on develop. Once a release is
>> stabilized the release branch is merged to master and develop.
>>
> This is the purpose of master, I would not make extra release branches,
> however this is close to being religious. If release branches are made they
> should solely relate to master, NOT to develop.
>
> Instead of a branch, which is a lot of overhead, I would just use the GIT
> id of master, to identify the original release.
When using the 'git-flow' extension, there's a sub-command that deals
with releases. A release is started from a commit on develop and when
finished merges it to master, merges to develop and creates a tag.
For anyone who's not tried this, I highly recommend creating a separate
test repo (you can do this locally), installing git-flow, and trying out
the commands.
p
>> 5) Maintenance branches are created after a release (off master) to
>> support ongoing hot fixes and patches as needed. This diverges slightly
>> from the “hotfix” model in the original gitlfow idea but works better for
>> releases with a longer life span.
>>
> +1, but it should be avoided, to keep the logistic (non-productive) work
> volume low, try to avoid making a hotfix for older releases.
>
>
>> Branch naming:
>> - master
>> - develop
>> - release/vVERSION
>> - maint/vVERSION
>>
>> where VERSION is semantic version name [3].
>>
>> Actions needed:
>>
>> 1) Create the develop branch off of master.
>> 2) Run nightly builds from the develop branch.
>>
> and e.g. weekly builds on master. Alternatively, whenever master is updated
> run a build.
>
> 3) Set the default branch for the repo to develop (is this possible with
>> the ASF git repo?).
>>
> yes
>
>> 4) Create a wiki page to codify the model and naming conventions.
>>
> +1
>
>>
>> Thoughts?
>>
> Please see my thought, not as an active developer, but as a mentor with
> experience from other projects.
>
>
>>
>> Anthony
>>
> nice suggestion.
>
> rgds
> jan i.
>
>>
>>
>> [1] http://nvie.com/posts/a-successful-git-branching-model/ <
>> http://nvie.com/posts/a-successful-git-branching-model/>
>> [2]
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>> <
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>>>
>> [3] http://semver.org <http://semver.org/>
>>
>>
>
--
[key:62590808]
Re: Branching model
Posted by jan i <ja...@apache.org>.
On 1 May 2015 at 15:53, Anthony Baker <ab...@pivotal.io> wrote:
> I suggest we adopt the gitflow model for branching as described in [1] and
> [2]. Following an established and consistent pattern for branching makes
> it easier for new users and devs to contribute.
>
> Here are the main gitflow concepts:
>
> 1) The master branch is reserved for production-ready code, aka releases.
> No changes are made directly on the master branch.
>
I would make an even tighter definition here.
Master is merged solely from develop, and only by the "release manager".
Merges can only be done, when build is successful on all supported
platforms, and
the tests on all supported platforms have passed.
>
> 2) The develop branch is the development mainline. Ongoing work shows up
> here first.
>
+1
>
> 3) Feature branches may be used to isolate interim work and will merge
> back to develop.
>
Public feature branches should only be used, when multiple people work on a
feature. A feature branch is started after the intention is made clear on
dev@
>
> 4) Release branches are created to allow a stabilization period for a
> release while not impacting ongoing work on develop. Once a release is
> stabilized the release branch is merged to master and develop.
>
This is the purpose of master, I would not make extra release branches,
however this is close to being religious. If release branches are made they
should solely relate to master, NOT to develop.
Instead of a branch, which is a lot of overhead, I would just use the GIT
id of master, to identify the original release.
>
> 5) Maintenance branches are created after a release (off master) to
> support ongoing hot fixes and patches as needed. This diverges slightly
> from the “hotfix” model in the original gitlfow idea but works better for
> releases with a longer life span.
>
+1, but it should be avoided, to keep the logistic (non-productive) work
volume low, try to avoid making a hotfix for older releases.
> Branch naming:
> - master
> - develop
> - release/vVERSION
> - maint/vVERSION
>
> where VERSION is semantic version name [3].
>
> Actions needed:
>
> 1) Create the develop branch off of master.
> 2) Run nightly builds from the develop branch.
>
and e.g. weekly builds on master. Alternatively, whenever master is updated
run a build.
3) Set the default branch for the repo to develop (is this possible with
> the ASF git repo?).
>
yes
> 4) Create a wiki page to codify the model and naming conventions.
>
+1
>
> Thoughts?
>
Please see my thought, not as an active developer, but as a mentor with
experience from other projects.
>
> Anthony
>
nice suggestion.
rgds
jan i.
>
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/ <
> http://nvie.com/posts/a-successful-git-branching-model/>
> [2]
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> <
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >
> [3] http://semver.org <http://semver.org/>
>
>
Re: Branching model
Posted by jan i <ja...@apache.org>.
On Monday, May 4, 2015, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Fri, May 1, 2015 at 9:53 AM, Anthony Baker <abaker@pivotal.io
> <javascript:;>> wrote:
> > I suggest we adopt the gitflow model for branching as described in [1]
> and [2]. Following an established and consistent pattern for branching
> makes it easier for new users and devs to contribute.
>
> +1 - makes sense to me.
>
> I personally prefer 'master' to be the unstable version that is always
> open for commits and having a separate 'stable' branch, but it's
> bike-shedding at that point.
+1 my point from earlier :-)
rgds
jan i
>
> Cheers. -- justin
>
--
Sent from My iPad, sorry for any misspellings.
Re: Branching model
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, May 1, 2015 at 9:53 AM, Anthony Baker <ab...@pivotal.io> wrote:
> I suggest we adopt the gitflow model for branching as described in [1] and [2]. Following an established and consistent pattern for branching makes it easier for new users and devs to contribute.
+1 - makes sense to me.
I personally prefer 'master' to be the unstable version that is always
open for commits and having a separate 'stable' branch, but it's
bike-shedding at that point.
Cheers. -- justin
Re: Branching model
Posted by Konstantin Boudnik <co...@apache.org>.
I am a huge fan, practitioner, and advocate for [1] - hence unconditional +1
Thanks,
Cos
On Fri, May 01, 2015 at 06:53AM, Anthony Baker wrote:
> I suggest we adopt the gitflow model for branching as described in [1] and
> [2]. Following an established and consistent pattern for branching makes it
> easier for new users and devs to contribute.
>
> Here are the main gitflow concepts:
>
> 1) The master branch is reserved for production-ready code, aka releases.
> No changes are made directly on the master branch.
>
> 2) The develop branch is the development mainline. Ongoing work shows up here first.
>
> 3) Feature branches may be used to isolate interim work and will merge back to develop.
>
> 4) Release branches are created to allow a stabilization period for a
> release while not impacting ongoing work on develop. Once a release is
> stabilized the release branch is merged to master and develop.
>
> 5) Maintenance branches are created after a release (off master) to support
> ongoing hot fixes and patches as needed. This diverges slightly from the
> “hotfix” model in the original gitlfow idea but works better for releases
> with a longer life span.
>
> Branch naming:
> - master
> - develop
> - release/vVERSION
> - maint/vVERSION
>
> where VERSION is semantic version name [3].
>
> Actions needed:
>
> 1) Create the develop branch off of master.
> 2) Run nightly builds from the develop branch.
> 3) Set the default branch for the repo to develop (is this possible with the ASF git repo?).
> 4) Create a wiki page to codify the model and naming conventions.
>
> Thoughts?
>
> Anthony
>
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/>
> [2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow>
> [3] http://semver.org <http://semver.org/>
>
Re: Branching model
Posted by Lyndon Adams <ly...@gmail.com>.
Since using this git flow for a while now I would strongly back the take up of this branch process.
Lyndon Adams
London, SW11
> On 1 May 2015, at 17:44, Dan Smith <ds...@pivotal.io> wrote:
>
>> On Fri, May 1, 2015 at 6:53 AM, Anthony Baker <ab...@pivotal.io> wrote:
>>
>> I suggest we adopt the gitflow model for branching as described in [1] and
>> [2]. Following an established and consistent pattern for branching makes
>> it easier for new users and devs to contribute.
>>
> +1
>
> Should we also standardize on using the git-flow tool to manage branches?
> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
Re: Branching model
Posted by Konstantin Boudnik <co...@apache.org>.
On Sun, May 03, 2015 at 07:02PM, Dan Smith wrote:
> >
> > Can you elaborate on what do you mean by 'standardize'. To my knowledge
> > the model that Anthony is describing (which, btw, I really like) is
> > possible
> > with any tools. Or even without tools -- just with bare git.
> >
> >
> Sure. By 'standardize' I mean (a) recommending people use the git-flow,
> and (b) asking the people follow the process strictly enough to match what
> the tool is doing. The process certainly doesn't require the tool and
> committers shouldn't have to use it, but it helps define precisely what the
> process should be and it makes it easier for people if they do want to use
> it.
In case it hasn't been said out loud: git-flow is the extension for git, that
"enforces" the git branching model, offered by OP.
Cos
Re: Branching model
Posted by Dan Smith <ds...@pivotal.io>.
>
> Can you elaborate on what do you mean by 'standardize'. To my knowledge
> the model that Anthony is describing (which, btw, I really like) is
> possible
> with any tools. Or even without tools -- just with bare git.
>
>
Sure. By 'standardize' I mean (a) recommending people use the git-flow,
and (b) asking the people follow the process strictly enough to match what
the tool is doing. The process certainly doesn't require the tool and
committers shouldn't have to use it, but it helps define precisely what the
process should be and it makes it easier for people if they do want to use
it.
-Dan
Re: Branching model
Posted by Roman Shaposhnik <rv...@apache.org>.
On Fri, May 1, 2015 at 11:44 AM, Dan Smith <ds...@pivotal.io> wrote:
> On Fri, May 1, 2015 at 6:53 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
>> I suggest we adopt the gitflow model for branching as described in [1] and
>> [2]. Following an established and consistent pattern for branching makes
>> it easier for new users and devs to contribute.
>>
> +1
>
> Should we also standardize on using the git-flow tool to manage branches?
> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
Can you elaborate on what do you mean by 'standardize'. To my knowledge
the model that Anthony is describing (which, btw, I really like) is possible
with any tools. Or even without tools -- just with bare git.
Thanks,
Roman.
Re: Branching model
Posted by Roman Shaposhnik <rv...@apache.org>.
On Fri, May 1, 2015 at 11:44 AM, Dan Smith <ds...@pivotal.io> wrote:
> On Fri, May 1, 2015 at 6:53 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
>> I suggest we adopt the gitflow model for branching as described in [1] and
>> [2]. Following an established and consistent pattern for branching makes
>> it easier for new users and devs to contribute.
>>
> +1
>
> Should we also standardize on using the git-flow tool to manage branches?
> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
Can you elaborate on what do you mean by 'standardize'. To my knowledge
the model that Anthony is describing (which, btw, I really like) is possible
with any tools. Or even without tools -- just with bare git.
Thanks,
Roman.
Re: Branching model
Posted by Dan Smith <ds...@pivotal.io>.
On Fri, May 1, 2015 at 6:53 AM, Anthony Baker <ab...@pivotal.io> wrote:
> I suggest we adopt the gitflow model for branching as described in [1] and
> [2]. Following an established and consistent pattern for branching makes
> it easier for new users and devs to contribute.
>
+1
Should we also standardize on using the git-flow tool to manage branches?
http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
Re: Branching model
Posted by Pid <pi...@pidster.com>.
On 01/05/2015 14:53, Anthony Baker wrote:
> I suggest we adopt the gitflow model for branching as described in [1] and [2]. Following an established and consistent pattern for branching makes it easier for new users and devs to contribute.
>
> Here are the main gitflow concepts:
>
> 1) The master branch is reserved for production-ready code, aka releases. No changes are made directly on the master branch.
>
> 2) The develop branch is the development mainline. Ongoing work shows up here first.
>
> 3) Feature branches may be used to isolate interim work and will merge back to develop.
>
> 4) Release branches are created to allow a stabilization period for a release while not impacting ongoing work on develop. Once a release is stabilized the release branch is merged to master and develop.
>
> 5) Maintenance branches are created after a release (off master) to support ongoing hot fixes and patches as needed. This diverges slightly from the “hotfix” model in the original gitlfow idea but works better for releases with a longer life span.
>
> Branch naming:
> - master
> - develop
> - release/vVERSION
> - maint/vVERSION
>
> where VERSION is semantic version name [3].
>
> Actions needed:
>
> 1) Create the develop branch off of master.
> 2) Run nightly builds from the develop branch.
> 3) Set the default branch for the repo to develop (is this possible with the ASF git repo?).
> 4) Create a wiki page to codify the model and naming conventions.
>
> Thoughts?
>
> Anthony
+1
p
> [1] http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/>
> [2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow>
> [3] http://semver.org <http://semver.org/>
>
>
--
[key:62590808]