Re: [linuxtools-dev] API breaks and branching strategy

[Alexandre Montplaisir <alexandre.montplaisir@xxxxxxxxxx>]

On 12-06-29 02:59 AM, akurtakov wrote:
>> So no API break in 'master' before SR2 (including November LT v2.0)? Fine
>> with me.
> The proposal for November Linux Tools 2.0 was in order to make it
> easier to get your API breaking things in. If we manage to not break
> the API the release should be 1.2 to reflect the pure addition of
> features. I really hope that this is what will happen.

Oh, if the November release is 1.2, it makes it easier then.

We know pretty much for sure that:
- We will be working on API-breaking features, and some of them will
happen after November. At most until March, as François mentioned.
- We will want those features delivered as part of the Kepler release.

However, I don't think we'd have any problems simply working in a
separate "kepler" branch for now, and then after November merge it into
master with master bumping to 2.0.

>
>>
>> Which, after much clarifications, brings us back to square two (Alexandre's
>> second question): is there a preferred way to handle/avoid conflicting
>> "@since X.Y" between these branches?
> Well, if you do your api changes in a branch and skip the release (or
> push just bugfixes to it) all your @since tags would be in the branch
> untill merged so there shouldn't be that much conflicts or I miss
> something? But if a method was added in the 2.0 branch and gets
> backported to e.g. 1.1 the @since in every branch should be 1.1 as it
> should always state the version we released this API to our users.

The problem is with the way the API tool in Eclipse works. It seems it
was made for a workflow where you are only working on one new version at
a time.

Let's suppose I clone the master branch, then set up the 1.0 baseline as
was discussed previously [1].
>From there we can introduce "@since 1.1" changes in the master branch,
we get warnings for new methods, etc., everything works fine.

But then if I create a new "lttng/kepler" branch locally, and bump the
plugins' versions in the Manifests to 2.0.0 in that branch, I start
getting errors where the "@since 1.1" annotations should in fact be
"@since 2.0". This is because 1.1 is not in the baseline, and since the
plugins are marked as 2.0.0, it expects all new methods to be marked
@since 2.0.


One potential solution would be to clone the master (1.1) branch in a
separate directory, then use that directory as a baseline. But then we
would have to regularly pull to update that branch, so the latest 1.1
API shows up in our workspace's baseline. This does not seem very clean
though, and we were wondering if a better method existed.



[1] http://dev.eclipse.org/mhonarc/lists/linuxtools-dev/msg02014.html

Cheers,

-- 
Alexandre Montplaisir
DORSAL lab,
École Polytechnique de Montréal