[tracecompass-dev] Master branch: 2.0 or 1.1 ?

[Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>]

Hi all,

Branching off (pun intended) the discussion here to talk about our 
branching strategy for SR releases and Eclipse Neon.

From the way I see it, we basically have 2 options:
1) Bump master to 2.0 right away, allowing API breaks all around. Then 
build the SR releases from the stable-1.0 (which would rather become a 
stable-1.x) branch.
2) Bump master to 1.1, and build SR releases from there. Since You Can't 
Stop Progress (tm), this would imply having to create a -neon branch, 
which could contain API breaks, and to which we would regularly merge 
from master.

I am strongly in favor of option 1). We used the option 2) workflow back 
in Linux Tools for about one full release and a half, and it was a 
*major* *pain*.

To show how limiting it is to not allow API breaks in master, consider 
this : 1.0 is not even released yet, and we already have such API breaks 
in master!
(About this, I recommend to all contributors to setup their 1.0 baseline 
in their workspace, so that they can be made aware of these breaks. It 
is now much easier to do, thanks to targets-as-baselines. I have updated 
the instructions to do so at [1].)
So if we were to go with 2), we would have to rectify this first.

Thoughts, comments?

Cheers,
Alex


[1] 
https://wiki.eclipse.org/Trace_Compass/Development_Environment_Setup#Define_an_API_baseline