Moreover, we had very similar flow and quit using it in favor of current process.
Thanks! Yakov On Sep 10, 2015 13:30, "Sergi Vladykin" <[email protected]> wrote: > 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 <[email protected]>: > > > 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 < > [email protected]> > > 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 < > [email protected]> > > > 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. > > > > > > > > > >
