Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] API breaks and branching strategy

On 12-06-28 03:54 PM, akurtakov wrote:
> On Thu, Jun 28, 2012 at 10:47 PM, Alexandre Montplaisir
> <alexandre.montplaisir@xxxxxxxxxx> wrote:
>> Hello Linux Toolers,
>>
>> We of the LTTng group already have some changes in the pipeline that
>> will break our 1.0 API. If I understood correctly, the 1.1, 1.2, etc.
>> releases (if applicable) will be based off the current stable-1.0
>> branch, not the master. Does this mean we can switch our plugins to
>> 2.0.0 in git master, and start pushing API-breaking changes right away
>> (with the relevant "@since 2.0" annotations) ?
> No. 1.0.z releases will be made from stable-1.0.

Ok, this is what I thought at first, it indeed makes more sense.

> And IBM guys are
> going to make 1.1 at the end of July with focus on remote enablement
> of tools. This work happens in master. I would say that if LTTng wants
> to go to 2.0 and no one objects it being so soon  after our 1.0
> release you can do that development in feature branch in order to not
> break the api for 1.1. Also you should be sure that whatever changes
> you plan for 2.0 will last for longer period as with every next major
> release I would like to see us really having an API that we stick to
> for a year.

Thing is, there is a lot of development going on in TMF/LTTng, with many
features planned for the next year already. State system partial
histories, trace synchronization, streaming, CTF reading/writing, etc.
and each of those will most probably break our API too. (on a side note,
I personally think LTTng should have remained in incubation, but well,
too late for that now...)

I just talked with François, what we could do is start a lttng/kepler
branch, and we'll use it as our "master" until 2.0 opens in the real
master. In such a case, would it be possible to have that branch also be
built on Hudson to benefit from the CI?


Thanks,

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



Back to the top