[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[linuxtools-dev] API for 1.0
|
Hi everyone,
One more boring email:)
In preparation for our 1.0 release we finally come to a state where we have to care about an API. Something we have never done before in this project so there will be hard issues to fix I'm sure.
First of all we should follow Eclipse Naming Conventions (http://wiki.eclipse.org/Naming_Conventions) which in our case means that everything in org.eclipse.linuxtools.<subproject> packages is considered an API for 1.0 release. If you don't want to sign for something being an API please move it to org.eclipse.linuxtools.internal.<subproject> packages. Note that the internal package names should be org.eclipse.linuxtools.internal.<subproject> package hierarchy not org.eclipse.linuxtoools.<subproject>.internal hierarchy.
I have modified the hudson and tycho build to generate the javadocs for what we have now as public API. You can see it at https://hudson.eclipse.org/hudson/job/linuxtools-master/javadoc/ and it is regenerated on every build. If someone has to export somepackage but is not sure about the API please read http://wiki.eclipse.org/Provisional_API_Guidelines and bring the question on this mailing list so it can be collectively decided.
The number of classes exported as API now is surprisingly big, especially for 1.0 release so please consider reducing the API as we should have to keep this API for the whole Juno timeframe. As we should create apibaselines for our 1.0 release API changes will be automatically detected resulting in problems changing things if they are exported as an API but weren't intended.
It is fine to ignore this mail completely and expose everything if you are ready to stick to the API and only add to it for sometime.
P.S. Jeff, autotools is moving to cdt soon, right? In this case autotools shouldn't be affected as it won't be in our 1.0 release.
P.S. 2: I know that life is not that simple but after reviewing rpmstubby some time ago and refactoring it a bit I ended with having only one class and one enum as public api which at the same time eased integration in eclipse-fedorapackager so thinking about the API really pays off easily. https://hudson.eclipse.org/hudson/job/linuxtools-master/javadoc/org/eclipse/linuxtools/rpmstubby/package-summary.html
Alex
