ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Git branches and development process.
Date Wed, 03 Jun 2015 10:51:02 GMT
This approach doesn't work well when there are several development
branches. E.g. someone is working on tickets for current release, someone
else is working on features for the next release. Current approach with
"sprint" branches handles this situation.
Another problem is that version is subject to frequent changes and can vary
for the same set of features depending on some "political" and "marketing"
reasons. Normally developer should not be aware of versioning. This is why
indirection between sprint and version is a good thing.

On Wed, Jun 3, 2015 at 1:25 PM, Artiom Shutak <ashutak@gridgain.com> wrote:

> Igniters,
>
> As I remember, the question about hard understandable Ignite branches
> system was discussed many times. But I don't remember the end of it story.
>
> I suggest to have next branches system (nothing new).
>
>    - *development* branch. The branch has the last development state with
>    all new features. If you start development new feature, you just make
>    branch from the HEAD of *development* branch and create a patch against
>    this one.
>    - *master* branch. The branch has the same state as the last released
>    version of Ignite. As a result, when anyone clone Ignite, he will see
>    stable version of Ignite and can simply play with him.
>    - *release-x.x.x* branches. When we think, that development branch has
>    enough new features for release, we just create new *release-x.x.x*
>    branch and make Ignite stable here. After releasing of this branch, we
> need
>    to merge* release-x.x.x *branch at *development* and at *master*
>    branches.
>
>
> To get this branches state, we need to
>
>    - "rename" *ignite-sprint-6* to *development*
>    - "rename" *ignite-sprint-5 *to* release-1.2.0*
>    - merge last released branch at *master *(if we didn't do it yet)
>
> // "rename" = create new branch from the HEAD of old branch and delete old
> branch.
>
> I think this schema will be more clear for contributors, commiters and
> simple users.
>
> Thoughts? Objections?
>
> -- Artem --
>

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