On Thu, Jun 28, 2012 at 6:38 PM, akurtakov <akurta...@gmail.com> 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... 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. 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'... 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. 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? -- Francois
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
