On Tue, Nov 17, 2009 at 9:47 AM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > On Tue, Nov 17, 2009 at 9:24 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: >> ...Again, with proper tooling all of this is no problem.... > > And we don't have such tooling, or do we?
I know that the eclipse pde people are working on this kind of stuff. I think it might be possible to build something around their api tools: http://eclipsesource.com/blogs/2009/07/08/osgi-eclipse-and-api-management/ Not sure how easy it would be to use it for our purposes but it sure would be great to have something in this area. Regarding the burden on the user see my other mail where i show how bnd can be configured to do the correct thing based on the versionpolicy feature of bnd. regards, Karl > I see the logic in Felix's reasoning, but without tooling I think the > burden on developers (and on users trying to make sense of a myriad > version numbers) is too high. Not because we are too lazy to do it, > but because more work means more room for failure. > > As for tooling, something that computes digests on the source code of > packages, and checks that the version numbers change when the > aggregated digests of a given package change, would at least make it > possible to know when package version numbers need to change. > > Also, maybe this version management scheme makes sense for a small > number of our bundles (like the API bundles), in which case we might > agree to use this scheme just for those few bundles - which also > rarely change, making that more manageable. > > -Bertrand > -- Karl Pauls karlpa...@gmail.com
