+1 Vova On Wed, Jun 3, 2015 at 1:51 PM, Vladimir Ozerov <[email protected]> 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 -- > > > -- Sergey Kozlov GridGain Systems www.gridgain.com
