[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Platform/JDT/PDE Committers Please Read: Git development process
|
> - Two main branches called "develop" and "master"
> - All major feature work is first released to "develop"
> - Each team periodically merges "develop" into master after performing
their appropriate checks and tests (similar to our current weekly tag and
release process)
> - Integration builds automatically tag and build the contents of
"master"
This direction sounds good to me with some modifications and thoughts:
- I would name the dev branch 'master' as it's natural for Git developers
to contribute to the 'master' branch.
- Call the integration/stable branch 'integration' or 'build'. "Normal"
committers would not touch that branch, only the one responsible for the
(weekly) build input would do so after running all the tests.
- Unless we can automate this in some way (e.g. like Ian proposed in his
e-mail) we still need to keep the map files in order to satisfy p2 as we
only want to build and put the changed bundles into the p2 repo. The build
script can tag the repositories as suggested, then compare with the
version currently in the map file and if needed update the map file with
the new tag. Then build as today.
- We need to clearly specify the tag name scheme for all our build types
and make sure they are in strictly ascending order for newer
builds/bundles.
Dani
eclipse-dev-bounces@xxxxxxxxxxx wrote on 12.10.2011 20:18:53:
> From:
>
> John Arthorne <John_Arthorne@xxxxxxxxxx>
>
> To:
>
> eclipse-dev@xxxxxxxxxxx
>
> Date:
>
> 12.10.2011 20:26
>
> Subject:
>
> [eclipse-dev] Platform/JDT/PDE Committers Please Read: Git development
process
>
> Now that we are becoming more familiar with Git, we should have a
discussion about our team development processes and consider changes that
are more suitable to our new tools. In particular, our existing release
process of tagging and map files were designed for the CVS world where
moving code between branches was painful. This process is not adapting
well to Git. For example, you can't reliably checkout a branch or tag that
matches what was in a given build, and there is no clear way to apply
release tags such as "R3_7_1" because no single commit is guaranteed to
represent the built contents of all bundles in that repository.
>
> If you think about it, our map files effectively superimposed another
branch on HEAD, with the precise contents of that branch defined by the
map tags for each project. This allowed us to do things like proceed with
new work in HEAD without disrupting rebuilds, or revert a change by
altering the map file (because backing out changes that span multiple
files in CVS is painful). With Git, the more natural expression of this
setup is to have two branches: one for integration builds and one for
ongoing work that we want to test and share with other teams but not
submit to a build. It turns out that there is a popular Git development
process similar to this, called git-flow [1]. I think a simplified form of
git-flow would match our current development practices:
>
> - Two main branches called "develop" and "master"
> - All major feature work is first released to "develop"
> - Each team periodically merges "develop" into master after performing
their appropriate checks and tests (similar to our current weekly tag and
release process)
> - Integration builds automatically tag and build the contents of
"master"
>
> With this approach each tag on master represents a build. This makes it
easy for anyone to checkout the contents of any particular build even if
it spans multiple Git repositories. This also allows you to revert a build
submission or make a surgical fix for a rebuild without disrupting the
ongoing work in the develop branch. We could also adopt other aspects of
git-flow such as release branches for our end-game period, although I'm
not convinced we need it.
>
> After that long-winded explanation, my request is that all teams think
about their development practices and how they can be adjusted or improved
in our new Git setup. Read up on git-flow and think about how it applies
to our development process. If you're interested you might also want to
look at other processes such as github-flow [2] for an alternate
viewpoint. Talk about it within your team, and we'll aim to have a general
discussion about it at next week's planning call (Wednesday October 19th,
11am EDT). If you don't normally join that call, send feedback to your
team lead, or you're welcome to join next week's call to chime in. I don't
think we'll arrive at a perfect development process overnight, but we can
start to make changes and refine it as we go forward.
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
> [2] scottchacon.com/2011/08/31/github-flow.html
>
> John _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
