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

[akurtakov <akurtakov@xxxxxxxxx>]

On Fri, Jun 29, 2012 at 8:39 AM, Francois Chouinard
<fchouinard@xxxxxxxxx> wrote:
>
> On Thu, Jun 28, 2012 at 6:38 PM, akurtakov <akurtakov@xxxxxxxxx> wrote:
>>
>>
>> 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.
>
>
>
> LTTng itself has very few API:s so not much to worry on that front.
>
> It's the underlying frameworks/components (used by the LTTng plug-ins, as
> well as other internal products) that are more likely to be
> augmented/impacted when new features are introduced.
>
> Since they are mostly FW API:s, it's not such a great idea to hide them.
>
> Also, while using 'ISomething2' is certainly good enough for a maintenance
> release, in my mind it just adds entropy to your API:s and you should weigh
> the option of biting the bullet and clean up when a new major version is in
> the queue.
>
> Finally, the people using the FW API:s are likely app designers that are
> probably hooked directly to latest from 'master' or stable-X.Y anyway (TBC).
> Although I doubt that they appreciate the rug being pulled from under their
> feet, they are probably aware that 'master' should be considered unstable to
> a certain extent.
>
> Don't get me wrong: I'm all for stable API:s but my reality is that the
> LTTng tool itself (the thing we wrap) is going through changes and
> enhancements at an entertaining rate...

That's really cool and I really understand the need to break API.
Don't get me wrong :) - I'm the one pushing for most api breakage on
Fedora Java side to get rid of old crap but never in a released
version or updates to it. And that's how I see the SR1 and SR2 so I
look for no API breakages for June-January or even June-November if we
decide that a possible November release will be what we contribute to
SR2 builds.

>
>
>> 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.
>
>
>> 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.
>>
>
> So no API break in 'master' before SR2 (including November LT v2.0)? Fine
> with me.

The proposal for November Linux Tools 2.0 was in order to make it
easier to get your API breaking things in. If we manage to not break
the API the release should be 1.2 to reflect the pure addition of
features. I really hope that this is what will happen.

>
> I presume that an LT November non-API-breaking v2.0 would be to highlight
> that we have new, stabilized features (or something along these lines) like
> remote execution.
>
> On our side, since we are currently planning the features we would like to
> contribute for Kepler and considering that requirements will trickle in
> during the coming year, it is not obvious that these API:s will be finalized
> in November. So, even if we keep out of a non-API-breaking November LT v2.0,
> our subsequent contribution will probably be API-breaking thus forcing a
> major version bump when the naughty branch is merged back in 'master'...

Once the SR2 contribution is finalized or even at least branched I'm
pretty fine with getting API breaking branches merged in and bumping
majors.

>
> Anyway, an lttng-kepler branch is fine with me. In fact, we could even
> consider a linuxtools-kepler branch for all those API-breakers :-) However,
> it would still be nice to have Hudson nightly builds for that branch, if
> possible.

It is - just request a build
http://wiki.eclipse.org/Common_Build_Infrastructure/Getting_Started/Build_In_Hudson#Request_a_job
. I'm pretty sure that the webmasters would even clone our
linuxtools-master to linuxtools-kepler so the config should be as easy
as pointing hudson to new branch name. I assume such job will be used
by other projects if they decide to go your route and skipping a
release and start working on api changes earlier, right? I can even
handle this with webmaster once we have a branch to build.

>
>
> Which, after much clarifications, brings us back to square two (Alexandre's
> second question): is there a preferred way to handle/avoid conflicting
> "@since X.Y" between these branches?

Well, if you do your api changes in a branch and skip the release (or
push just bugfixes to it) all your @since tags would be in the branch
untill merged so there shouldn't be that much conflicts or I miss
something? But if a method was added in the 2.0 branch and gets
backported to e.g. 1.1 the @since in every branch should be 1.1 as it
should always state the version we released this API to our users.

Alex



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