Very good point!
On Thu, Jun 5, 2008 at 4:17 PM, Peter Kriens <[EMAIL PROTECTED]> wrote: > I think one of the key things we are missing is that there seems to be sides > to > versioning. This difference is very visible with interfaces. > > If you add a method to an interface than the implementer can not live with > the new version but the client is perfectly happy. I.e. it is quite easy to > keep the client happy by being backward compatible but the implementer of > the > interface has much more stringent requirements. An implementer must > match the specification version 100%. > > If you implement the log service, your Import-Package for the > org.osgi.service.log > MUST be a point release. You do not want to accidentally implement a later > release. > However, if you use the log service, point->infinite > is usually good enough. Or if you're anal, point to next incompatible > release. > > Kind regards, > > Peter Kriens > > > > > > > On 5 jun 2008, at 03:02, Jeff McAffer wrote: > >> The Eclipse versioning conventions can be found here >> http://wiki.eclipse.org/index.php/Version_Numbering >> >> As for tooling, PDE now (as of 3.4) includes some API tooling that helps >> with version numbering violations and breaking API changes (amongst other >> things). See >> http://wiki.eclipse.org/Api_Tooling >> >> What is missing: >> - package version number management. We just ran out of time to do this. >> Expect it as one of the first things done in the next release cycle. >> >> - compiling against lower bounds. To really be sure that you are only >> using >> things provided by the lower bound version of your prereqs you should >> compile against it (or have kick ass tooling that validates your API use). >> This may actually be coming >> >> - automatic generation of import version bounds. This is actually a very >> hard problem. Setting the lower bound automatically purely from an API >> signature basis it is tractable IF you have copies of all versions of the >> package API signatures available to you. Then you could do some sort of >> analysis and discover that the code calls only the API included in version >> 1.2.3 or later (for example). Pragmatically however, there may be other >> API >> considerations that come into play (e.g., semantic changes, contract >> clarifications, ...). Then there is the compilation problem (see above). >> On top of that there are context issues where it may not even make sense >> for >> you to import org.foo 1.2.3 with org.bar 3.2.1 even if technically the API >> signature constraints are met. Oh, and then there is testing. >> >> I am a very strong believer in developer defined dependencies. Tooling is >> essential in making this easy (we are getting there with PDE and bnd) but >> to >> create well-engineered components one must pay close attention to your >> dependencies. Reverse-engineering them from developed code can provide a >> great starting point and tools can help you stay in the bounds that you >> defined based on that starting point but ultimately a real live human >> developer needs to be involved in crafting these dependencies. >> >> The packages and versions you choose basically define the contract you are >> committing to. A lower lower bound means that you are constraining >> yourself >> to use only a certain level of function in a certain series of YOUR >> bundles. >> Raising your lower bound in a service release of your bundle for example >> can >> cause people's applications to stop running/resolving (they may not be >> able >> to supply the new version of the prereq). >> >> A higher upper bound means you are willing to take on more risk in your >> bundle as a wider range of changes in your prerequisites is going to be >> tolerated. You have to trust the producer to be reasonable and write your >> code to be robust. >> >> There is no silver bullet here IMHO. The tooling can be improved but >> ultimately the burden belongs to a developer. In fact, in several >> projects >> I know of it is the architects and senior people who design these >> dependencies. They don't just appear because some developer hit >> Ctrl-space >> and autocompleted to include whole new reams of function. >> >> Jeff >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:osgi-dev- >>> [EMAIL PROTECTED] On Behalf Of Mirko Jahn >>> Sent: Wednesday, June 04, 2008 7:34 PM >>> To: OSGi Developer Mail List >>> Subject: Re: [osgi-dev] Version constraints used in Import-Package >>> >>> Well, unfortunately this is kinda true. I think the spec is great in >>> terms of capabilities, but first of all everyone needs to understand >>> the implications of version number schemes. OSGi is great to gain >>> quick benefits, but if it is adapted in a very simple way (only plain >>> exports without version numbers, imports without version ranges and so >>> on) the benefits are very limited. Actually, I even think it might >>> cause sooner or later real problems with interoperability. More in the >>> terms of awareness and training should be done. Otherwise we might end >>> up with thousands of bundles not worth a thing, because we can't rely >>> on them. Everything has to be done by hand. The ultimate goal should >>> be to have tooling support to automatically generate these numbers. >>> The tool should detect version changes between releases on a semantic >>> and syntactic level and change the version numbers accordingly. No >>> human interaction should be required. This is the way to go I think. >>> The only thing the bundle developer should be involved with is >>> defining the version to export - even imports with version ranges >>> should be handled by the tool. This would leverage software reuse and >>> put modularization on a completely new level! Well, although this is >>> not impossible, it is far from reality right now and it is certainly >>> not part of a specification. It would be interesting if someone is >>> already working on something like this. I know Eclipse 3.4 is trying >>> to do things like that, but till now I couldn't find any documentation >>> on that. If some knows anything, I would be interested to know about >>> it! >>> >>> Cheers, >>> Mirko >>> >>> On Wed, Jun 4, 2008 at 5:24 PM, Alan Cabrera <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> On Jun 4, 2008, at 1:21 AM, Rajini Sivaram wrote: >>>> >>>>> >>>>> Thank you all for the replies with all the useful information and >>>>> pointers. >>>>> >>>>> For versioning Tuscany bundles themselves, we are using >>>>> maven-bundle-plugin at the moment, which gives us import and "uses" >>> >>> clauses >>>>> >>>>> with version="2.0.0". Since this includes all versions from 2.0 to >>> >>> infinity, >>>>> >>>>> and we are not currently addressing execution of two different >>> >>> versions of >>>>> >>>>> Tuscany side-by-side, the default looks sufficient. We could change >>> >>> it to >>>>> >>>>> "[2.0.0,3.0.0)" to make it more specific, but either way, it should >>> >>> be fine >>>>> >>>>> for now. >>>>> >>>>> I am still not entirely sure about versioning of 3rd party libraries >>>>> distributed with Tuscany though. Since Tuscany is used to assemble >>> >>> SOA >>>>> >>>>> applications, Tuscany uses a large number of 3rd party libraries to >>> >>> provide >>>>> >>>>> different bindings and implementation types. Many of these 3rd party >>>>> libraries may also be used by applications (either directly from >>> >>> Tuscany or >>>>> >>>>> from a different source). If for example, Tuscany's version of >>> >>> wsdl4j used >>>>> >>>>> import version "[1.6.2, 2.0,0)", and this version of Tuscany doesn't >>> >>> work >>>>> >>>>> with wsdl4j version 1.7, doesn't the version range "[1.6.2, 2.0,0)" >>> >>> prevent >>>>> >>>>> an application from installing and using version 1.7 along with >>> >>> Tuscany for >>>>> >>>>> something else? So should the version range only specifically >>> >>> include the >>>>> >>>>> version range that Tuscany has been tested against? And then we run >>> >>> into >>>>> >>>>> problems with too narrow version ranges. And what happens when an >>>>> application is using wsdl4j from SpringSource or another repository >>> >>> where a >>>>> >>>>> different version range is included? How do we ensure that Tuscany >>> >>> and >>>>> >>>>> applications can all coexist? >>>> >>>> Ahh, and here we find that OSGi has the same achilles heel as Maven. >>> >>> I >>>> >>>> anticipate that these kind of issues will be the basis for a shrill >>> >>> of >>>> >>>> complaints as they are in Maven. >>>> >>>> I've had a fair bit of experience wiring in large sets of 3rd party >>> >>> jars. >>>> >>>> No one follows any single kind of version nomenclature and many >>> >>> violate the >>>> >>>> ones they espouse. >>>> >>>> Setting a version range in anticipation of what down stream >>> >>> application >>>> >>>> assemblers will use will be a futile task. Only the Pope and my >>>> mother-in-law are infallible and you're sure to get it wrong for some >>>> significant part of your community. The best you can do is set the >>> >>> range >>>> >>>> for what is safe for Tuscany in the hopes of providing accurate >>> >>> information >>>> >>>> for down stream application assemblers. >>>> >>>> >>>> Regards, >>>> Alan >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
