[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Master branch: 2.0 or 1.1 ?
|
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?
