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. > > >
