I think current git process[1] is ok for now. The only rule that was broken here is not merging feature to master until it is complete and ready for release.
[1] https://cwiki.apache.org/confluence/display/IGNITE/Git+Process Sergi 2015-09-10 12:16 GMT+03:00 Raul Kripalani <r...@evosent.com>: > I suggest we settle on Gitflow as a branching model. > > This would mean creating an extra branch 'develop' which would be > equivalent to SNAPSHOT, while 'master' would point to the latest release > from the highest release line, e.g. if we have released 2.0.0 but still > maintaining a 1.5.x release line, master would point to 2.0.0 even if 1.5.2 > is more recent in time. > > Regards, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Thu, Sep 10, 2015 at 9:03 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > I agree. Going forward I think the master branch should only have > > production-ready code. If something is not ready, there is no need to > rush > > with merges to master - keep it in your own branch. > > > > On Thu, Sep 10, 2015 at 12:56 AM, Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > Igniters, > > > > > > It seems I was too optimistic about adding platforms into the nearest > > > release. While their are mostly ready for now, the keyword here is > > > "mostly". We still need to think about documentation, build layout, > > addinig > > > Windows agents to TeamCity, and so on. > > > > > > I reverted changes which could be visible to users back and returned > > > ignite-1.4 branch. Platforms will be released in the 1.5 release. > > > > > > Vladimir. > > > > > >
