I still doesn't understand how does this scheme handle several simultaneous "sprints" (in current terms).
Our sprints are usually relatively short (2-4 weeks). On the one hand, at the end of every sprint we usually have a week or so to stabilize it. During this time the sprint is not released yet, so it is still "development" branch in your terms. And there is still active development in this branch incluing bugfixes, finalization of some _almost_ ready features, critical last-minute-changes etc. On the other hand, at this time all new major features go to the next "sprint", not to the current, to avoid regressions. And this is not about a single feature as in the scheme above. This is about lots of feauters, which usually conflicts with each other and thus must be constantly accumulated in some other branch. This is why instead of sprint-5 (development) new-feature-1 (merge to development after release, in a week) new-feature-2 (merge to development after release, in a week) we have sprint-5 (development) sprint-6 (next sprint) new-feature-1 (merge to sprint-6 as soon as ready) new-feature-2 (merge to sprint-6 as soon as ready) I am certainly +1 for using the most common practices, so that adoption of new people is as easy as possible. But it seems that with proposed solutions we get rid of one problem immediately introducing another. Vladimir. On Sat, Jun 6, 2015 at 8:41 PM, Pavel Tupitsyn <[email protected]> wrote: > +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 >
