Hi, Am 06.06.2012 um 14:16 schrieb Gary Gregory:
> On Wed, Jun 6, 2012 at 8:12 AM, Felix Meschberger <fmesc...@adobe.com>wrote: > >> Hi, >> >> Am 06.06.2012 um 14:00 schrieb Gary Gregory: >> >>> Opening <CanOfWorms>... >> >> ;-) BTW: Thanks alot ! This is appreciated. >> >>> >>> Should Commons adopt OSGi Semantic Versioning [1] instead of defining our >>> own [2] (even though they might in effect be the same)? >> >> From my consumer's POV, yes -- at least for the package exports. I don't >> really care for the bundle/library versions. >> >>> >>> Should Commons layer its semantic version details on top of OSGi? >> >> Do you mean by duplicate export ? >> > > No, I am talking about our guidelines list in [2]. Should we follow OSGi > and add our guidelines in addition? It seems our list is more detailed > because it is geared specifically for Java. Let me comment (again, I am outside of Commons): Re Interface types: externals are exported and internals/privates are not exported in OSGi speak. Re Types of changes: On fully-compatible changes has an influence. The other types just cause different Import-Package statements on the bundle and as such have no influence on the Export-Package, which is discussed here. As for fully-compatible: I think this is where a refinement for OSGi semantic versioning would really take place. Re Release Types, Release Numbers, and Development States: These are mostly about library versions. I don't think this needs to be changed for OSGi semantic versioning. Finally: If you want to take OSGi semantic versioning serious, you might want to add a section to convey the recommendations for semantic versioning corresponding to the exported packages. So at the end of the day it would be an important point on the agenda of the release manager: To make sure the changes since the last release are reflected in the change (or non-change) of the versions of exported packages. This is probably one of the hardest tasks but to consumers definitely worth it (speaking from experience). Regards Felix --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
