Re: [tracecompass-dev] Master branch: 2.0 or 1.1 ?

[Patrick Tasse <patrick.tasse@xxxxxxxxx>]

Something that came to mind while reviewing https://git.eclipse.org/r/50309:

If we implement something in 2.0 branch that adds a non-breaking API, then it must be marked @since 2.0. If we then cherry-pick or merge it to 1.1 branch, then it must be changed to @since 1.1 in that branch. And when 1.1 is released then it should be changed back to @since 1.1 in the 2.0 branch.

So perhaps any bug fix or feature that is to be released in 1.1 should be designed and merged on that branch, then merged or cherry-picked to 2.0, not the other way around.

Marc-Andre also mentioned to me that it could be possible to have the baseline set by the target definition. Should we set the baseline of 2.0 branch to be the 1.1 stable branch nightly build?

On Tue, Jun 16, 2015 at 11:30 AM, Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx> wrote:

Oh and the worst conflicts... is when directories are renamed, and the
other branch worked (and keeps working) on the old files. There was a
few of those last year (linuxtools->tracecompass, lttng2.stuff,
os.linux, etc). So if you can guarantee, 100% (special look at Alex
here) that the directory schism is the last rename of this cycle, then
it might not be too bad.

The only other rename/move I could foresee in the near future would be splitting tmf.core/ui in smaller separate plugins. It sounds like it won't be an easy to rebase through that either :S
Maybe we can wait until we get to the final master-2.0 branch before doing this change.

Also, would it be possible to have API incubation? Something like, "this
is a class of tmf.core, that will be used by other plugins, so it's part
of the API, but that API may not be final, so be aware it might change
at anytime". It could be put internal, then x-friend with other plugins,
but tmf.core is not supposed to be aware of lttng2.kernel.core for
example. Because some times, we quickly develop an API in mars and
realize in july that a method is not exactly how it should be... oops...

I don't have the links at hand, but I remember reading about using "staging", just like "internal" in package names. You also mark those x-internal. That is a way to define that these packages are meant to be public at some point (unlike internal packages, which are designed to be internal forever), but that the final API is not entirely "baked" yet.

Perhaps we could start making use of this?

_______________________________________________
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