[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Master branch: 2.0 or 1.1 ?
|
Thanks for the explanation.
I'm not a committer, but here's my 2 cents: if the APIs are in the state that you describe and if the committers are willing to take the time stripping down into real APIs, then better go for it now rather than adding all sorts of IFoobar2 stuff (which just cause confusion and unnecessary work down the road).
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From: Alexandre Montplaisir [mailto:alexmonthy@xxxxxxxxxxxx]
Sent: Monday, June 15, 2015 5:13 PM
To: Oberhuber, Martin
Cc: tracecompass developer discussions
Subject: 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
