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

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

----- Original Message -----
> From: "Alexandre Montplaisir" <alexandre.montplaisir@xxxxxxxxxx>
> To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>, "akurtakov" <akurtakov@xxxxxxxxx>
> Sent: Thursday, June 28, 2012 11:24:04 PM
> Subject: 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...)

When a project goes out of incubation everything in it goes out of incubation there is no middle ground. Once a project is out of incubation it can setup its own incubator but it would be pretty weird to move lttng back to incubation and even if we do that it would have to be kept api stable for the whole juno timeframe.

>
> 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?

Well, a question about LTTng - If we go with another feature release in November timeframe and we mark it 2.0 in order to not make you develop separately can you make the api changes you need so we can do 2.x release in Kepler? Or there will be need for 3.0?
If the later I would prefer LTTng to develop in a branch until the API is stabilized (or hidden) so we don't have to bump our major for every release.

Alex

>
>
> Thanks,
>
> --
> Alexandre Montplaisir
> DORSAL lab,
> École Polytechnique de Montréal
>
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
>