Re: [gemini-dev] Status gemini blueprint + Spring 4.2.x

["Olaf" <olaf@xxxxxxx>]

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-commutative-upper-bounds)

 

If this test case green I’d say the branch should be merged to master.

 

Regards,

Olaf

 

From: gemini-dev-bounces@xxxxxxxxxxx [mailto:gemini-dev-bounces@xxxxxxxxxxx] On Behalf Of Florian Waibel
Sent: Dienstag, 15. März 2016 10:10
To: Gemini and sub-projects developer discussions <gemini-dev@xxxxxxxxxxx>
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/).

 

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