> > > When a project goes out of incubation everything in it goes out of > incubation there is no middle ground. Once a project is out of incubation > it can setup its own incubator but it would be pretty weird to move lttng > back to incubation and even if we do that it would have to be kept api > stable for the whole juno timeframe. > > Alexandre made that comment because he already knows that some of his upcoming work will likely break the current LTTng API. This is also true of other parts of LTTng. The reason for this is that LTTng is a bit more than an integration project and actual "tools" are constantly being developed on top of the existing code and the existing "tools". Also, the LTTng tracer itself (the thing we wrap) is in constant evolution and new features are regularly being added.
It is expected that new tools (trace analysis component) will trigger changes in the API: the framework part will have to be at least augmented, very likely re-factored here and there. We also expect some evolutive maintenance on the existing tools and some of it could also trigger API changes (although less likely). So, since we are anyway expecting major changes over the life of this product, our criteria for going out of incubation was simply the relative "stability" of the underlying framework API. In the team's opinion, it was OK to graduate for Juno. If we had waited for the perfect API:s, this thing would have stayed experimental forever. > > > > I just talked with François, what we could do is start a lttng/kepler > > branch, and we'll use it as our "master" until 2.0 opens in the real > > master. In such a case, would it be possible to have that branch also > > be > > built on Hudson to benefit from the CI? > > Well, a question about LTTng - If we go with another feature release in > November timeframe and we mark it 2.0 in order to not make you develop > separately can you make the api changes you need so we can do 2.x release > in Kepler? Or there will be need for 3.0? > If the later I would prefer LTTng to develop in a branch until the API is > stabilized (or hidden) so we don't have to bump our major for every release. > > Our intention was to limit ourselves to bug fixes and non-API breaking enhancements (the 1.x ones) for the duration of Juno and do the real work - enhancements, new features, etc - for Kepler (which would have been 2.0 for us). So, if a LT 2.0 is released in November, we can't guarantee that we won't break the API - again - for Kepler. We could possibly make that commitment (no major API break) after March 2013... (just in time for Kepler :-)) Assuming that we create a branch off master and do the bulk of our work on it, is there a possibility to also have a Hudson daily build job for it? Or, would it make more sense to have a general linuxtools-kepler branch right now for everyone (with Hudson support, of course)? Otavio's idea of making a stable-1.1 branch is fine but I'm afraid we will run into a similar issue for stable-1.2, stable-2.x, ... A question for Alex: Can we bump the LT major number in a Juno maintenance releases? Regards, -- Francois
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
