ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Git branches and development process.
Date Sun, 07 Jun 2015 13:44:51 GMT
+1

I think I like Brane's suggestion (and Cos suggested similar structure
before).

- Master should become the development branch for the next release.
- All individual ticket branches should be created off of the master branch.
- When we are working on the 2 releases in parallel, we should create a
special release branch and merge it back to master, once the master branch
has been released.
- Same CI rules as we have now apply - all tests must pass before the merge
to the master branch.

This structure is more intuitive and we will have easier structure for the
newcomers to understand.

I think we should have a vote on it. I will start a separate vote thread.

D.

On Sun, Jun 7, 2015 at 11:51 AM, Branko ─îibej <brane@apache.org> wrote:

> On 07.06.2015 08:35, Branko ─îibej wrote:
> >   * When you're ready to begin stabilization for a release, create a
> >     release branch (rel-1.2.x for example) from the master branch. Only
> >     bug fixes happen on the release branch. When you're happy with the
> >     stability of the release, just tag the release branch (e.g., 1.2.0)
> >     and publish. This now becomes the bugfix branch for the 1.2.x
> release.
> >       o Its up to you to decide how you fix bugs on the release branch;
> >         there are basically two ways to do this:
> >           + Fix all bugs on master and cherry-pick them to the release
> >             branch(es). This is the preferred method because it ensures
> >             that all bug fixes are present in all future releases.
> >           + Fix bugs on the release branches and merge them back to
> >             master. This works but
>
> ... requires careful tracking of which bugfix was merged to trunk and
> whether or not it was propagated to the other release branches, as
> appropriate.
>
> -- Brane
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message