+1 Artiom, Cos The link above describes a quite standard approach, familiar to majority of devs, I believe. I have seen it many times before, it works well for any VCS. Current approach with sprint branches is more confusing, and also requires changing default branch on TC each sprint. I hear "which is the default branch on TC at the moment" quite often.
Thanks, On Sat, Jun 6, 2015 at 2:37 PM, Konstantin Boudnik <[email protected]> wrote: > 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 -- > > > > -- -- Pavel Tupitsyn GridGain Systems, Inc. www.gridgain.com
