Actually, this approach works very well for the situation below. The way to
deal with it is explained here
http://nvie.com/posts/a-successful-git-branching-model/And has been discussed on this list a couple of times already. 'sprint-N' branch is not different from a 'development' branch, except that 'development' is always there, where N is increased all the time in 'sprint-N' schema. That's pretty confusing if you ask me. Another issue with sprint-branch model, is that it doesn't support sustaining releases in a transparent way, where's the one above (or similarly offered by Artiom) does. Cos On Wed, Jun 03, 2015 at 01:51PM, Vladimir Ozerov wrote: > 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 <[email protected]> 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 -- > >
signature.asc
Description: Digital signature
