[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Master branch: 2.0 or 1.1 ?
|
Hi Martin,
IMHO, Trace Compass right now is pretty bad with APIs, in the sense that
it exposes way too many of them. Many things are public simply because
back when they were added, nobody knew about the "x-internal" thing.
For instance, if we look at the two "API breaks" I mentioned in my
previous email: the first is in an interface specific to the CTF plugin,
that could and should be internal. The second is related to the specific
implementation of the Histogram view, so again not really something that
should be considered an API.
Before we can establish an API-deprecation plan that we can actually
follow, I estimate we'd need to:
1) Break down tmf.core/tmf.ui in several smaller plugins, to isolate the
core framework elements from Trace Compass' implementations.
2) Go through all plugins across the project, and mark internal those
that should be.
Once we go through this exercise, then we will be actually capable of
stricter API guidelines, like marking public elements @Deprecated for
the duration of a full release before they are removed.
Perhaps Neon is the perfect time to do this. All committers are meeting
this week, so I'll bring this issue up.
Of course, making public things internal *is* an API break ;) Which
brings us back to my original question: What should be do with the
master branch right now? Keep it at a very limiting 1.1, with all sorts
of IMyInterface2 workarounds, or do we clean-cut to 2.0, then work on
improving the APIs in general, so that 2.x can be sustained for more
than a few days?
Cheers,
Alexandre
On 2015-06-13 12:44 AM, Oberhuber, Martin wrote:
Hello,
As a consumer / adopter I'm wondering what is the nature of the API Breaks that you anticipate ?
I.e. what APIs would be affected and why is the API break considered better than trying to remain API compatible.
Is this written in a project plan somewhere ?
In case we are using APIs that are already scheduled for change, we'd like to know early so we can plan accordingly.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From: tracecompass-dev-bounces@xxxxxxxxxxx [mailto:tracecompass-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexandre Montplaisir
Sent: Friday, June 12, 2015 5:04 PM
To: tracecompass-dev@xxxxxxxxxxx
Subject: [tracecompass-dev] Master branch: 2.0 or 1.1 ?
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
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
