Hi Florian,
It appears the non-commutative-upper-bounds branch is just a test extension demonstrating expected behaviour (https://github.com/eclipse/gemini.blueprint/compare/master...non-commutativ e-upper-bounds) If this test case green Id say the branch should be merged to master. Regards, Olaf From: [email protected] [mailto:[email protected]] On Behalf Of Florian Waibel Sent: Dienstag, 15. März 2016 10:10 To: Gemini and sub-projects developer discussions <[email protected]> Subject: Re: [gemini-dev] Status gemini blueprint + Spring 4.2.x Hi Olaf, We are making good progress toward the gemini blueprint 2.0.0 release. Changes are on the build branch, and the CI is green as of today (see build-branch.xyz builds here <https://hudson.eclipse.org/gemini/view/blueprint/> https://hudson.eclipse.org/gemini/view/blueprint/). That's great news! Next, I would propose to proceed with a trunk-style git branch layout, i.e. maintaining dedicated release branches and cherry-picking to them from the master, aka trunk. The reason being that trunk-style is a bit better for large-scale refactoring then working with a lot of feature branches. +1 Most of the remaining branches, some of which seem a bit outdated, may go. I like the idea of cleaning up the branches and checked some of them: * 392500-recursive-types is merged into master * 377198 is closed as cannot reproduced Any idea what's the reason behind the branch "non-commutative-upper-bounds"? Regards, florian
_______________________________________________ gemini-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/gemini-dev
