Skip to main content

[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 Bernd,

As I pointed out in the other sub-thread, because we expose so many APIs, I feel we are not in a very comfortable position right now to commit to adding many features without bumping the major version. Doing so would mean a lot of IThing2 workarounds, and that's if we are even able to do so.

We've been asking ourselves this very question every cycle for the last 3-4 cycles now. At some point we will have to bite the bullet and do a major API cleanup, which will then allow us to commit to a more stable API. But, of course, such cleanup is an API break in itself... No matter what branch 2.0 is, we should try to fit the cleanup at some point within this cycle, so that at the same date next year, we don't have to jump to 3.0 right away like we do now.


I agree with Marc-André, that normally master represents the "latest". Here's an idea: instead of the stable-1.0 branch, we could start a new "stable-1.x" branch, possibly after the chain of move-to-subdir patches, so that we can continue to cherry-pick easily. We've tried the merge workflow the past 3 times, maybe we can give the cherry-pick workflow a try this time? (those patches could bypass Gerrit to make it simpler, just like the merge conflicts resolution also bypassed Gerrit the last few times)

Thoughts?

Alex


On 2015-06-15 03:25 PM, Bernd Hufmann wrote:
Hi Alex

I have a similar concern as Marc-Andre. If we aim for 2.0 in master right away (option 1), my concern is that Mars SR1 won't get much attention and new features won't be included in SR1. Developers tend to not backport them to older release baselines. That means that users of Trace Compass who rely on released versions (not nightly builds) would have to wait till June 2016 to get these features. I'm not sure how we can make sure that certain features and bugfixes would be in SR1 and later SR2 if we go with option 1. Any thoughts?

Bernd


On 06/15/2015 01:14 PM, Marc-André Laperle wrote:
Hi Alex,

The way I see it, the major difference between 1) and 2) is which version do we perceive as our main focus and what we want the community to see as the main focus. Contributors just clone and start working on master. I think for us (at least at Ericsson?) the main focus is 1.1. If master is 2.0, there are some concerns that people will not take care of backporting everything of value to 1.1 and the SR1 release will be light on content. But I do like the simplicity of master being "the latest and greatest" with everything permitted. I'm not sure it's enough counter weight to the risk of not having a feature rich 1.1.

Marc-Andre

________________________________________
From: tracecompass-dev-bounces@xxxxxxxxxxx [tracecompass-dev-bounces@xxxxxxxxxxx] on behalf of Alexandre Montplaisir [alexmonthy@xxxxxxxxxxxx]
Sent: Friday, 12 June 2015 11:03 AM
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


_______________________________________________
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



Back to the top