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

[akurtakov <akurtakov@xxxxxxxxx>]

On Fri, Jun 29, 2012 at 1:11 AM, Francois Chouinard
<fchouinard@xxxxxxxxx> wrote:
>>
>> 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.
>>
>
> Alexandre made that comment because he already knows that some of his
> upcoming work will likely break the current LTTng API. This is also true of
> other parts of LTTng. The reason for this is that LTTng is a bit more than
> an integration project and actual "tools" are constantly being developed on
> top of the existing code and the existing "tools". Also, the LTTng tracer
> itself (the thing we wrap) is in constant evolution and new features are
> regularly being added.
>
> It is expected that new tools (trace analysis component) will trigger
> changes in the API: the framework part will have to be at least augmented,
> very likely re-factored here and there. We also expect some evolutive
> maintenance on the existing tools and some of it could also trigger API
> changes (although less likely).
>
> So, since we are anyway expecting major changes over the life of this
> product, our criteria for going out of incubation was simply the relative
> "stability" of the underlying framework API. In the team's opinion, it was
> OK to graduate for Juno. If we had waited for the perfect API:s, this thing
> would have stayed experimental forever.
>
>>
>> >
>> > 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.
>>
>
> Our intention was to limit ourselves to bug fixes and non-API breaking
> enhancements (the 1.x ones) for the duration of Juno and do the real work -
> enhancements, new features, etc - for Kepler (which would have been 2.0 for
> us). So, if a LT 2.0 is released in November, we can't guarantee that we
> won't break the API - again - for Kepler. We could possibly make that
> commitment (no major API break) after March 2013... (just in time for Kepler
> :-))
>
> Assuming that we create a branch off master and do the bulk of our work on
> it, is there a possibility to also have a Hudson daily build job for it? Or,
> would it make more sense to have a general linuxtools-kepler branch right
> now for everyone (with Hudson support, of course)?
>
> Otavio's idea of making a stable-1.1 branch is fine but I'm afraid we will
> run into a similar issue for stable-1.2, stable-2.x, ...
>
> A question for Alex: Can we bump the LT major number in a Juno maintenance
> releases?

No. It has been agreed for years that maintenance releases are just
that maintenance. See
http://wiki.eclipse.org/Callisto_Coordinated_Maintenance for the
initial agreement. It has been relaxed a bit (just my observation)
lately allowing projects to add new features as long as they keep
compatibility. At least a numbef of projects did it. But providing new
major in maintenance release should be out of question.
Projects should try hard to not break API - the easiest way is to
export less but going the ISomething2 might be an option too.
We want to provide our work to customers faster, we want to ship in
maintenance releases that's why breaking API  is not something taken
easily.
Can we agree that projects that need to break API do it in their own
branch until SR2 is released? Unless there are more projects wanting
to do breaking changes when it would make sense to do that for the
whole project. But doing a release with breaking API preventing others
to ship in maintenance releases is not something I like.

Alex

>
> Regards,
>
> --
> Francois
>
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
>