Bugzilla – Full Text Bug Listing
| Summary: | Some features/bundles do not have 3-part version numbers | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> | ||||
| Component: | Cross-Project | Assignee: | David Williams <david_williams> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | caniszczyk, john.arthorne, matthias.sohn, mn, oisin.hurley, pascal, sbouchet | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
IIRC JGit and EGit have 3 digit version numbers because of version numbering rules in Maven which require that release versions have 3 digits [1]. There are quite some consumers of jgit consuming it via maven 2 dependencies. On the other hand OSGi allows 1-4 digit version numbers [2]. This has been discussed on the egit-dev list [3]. We want to ensure that same number means same version not regarding if the dependency is defined via maven or osgi. Hence we thought 3 digits would be the best compromise. [1] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html [2] http://www.osgi.org/Download/File?url=/download/r4v42/r4.core.pdf section 3.2.5 [3] http://dev.eclipse.org/mhonarc/lists/egit-dev/msg01099.html org.eclipse.stp.sca.csa.editor_1.0.0 has been updated to 2.1.0_qualifier, rebuilt and the contribution updated in the Helios .build file. The most important principles are: 1) each unique set of bits has a unique version number. I.e., every build has a unique version number 2) version numbers increase across builds 1) is important because there are servicability problems if there are different builds with the same version. Say a user reports a problem with 0.8.1, but there were multiple builds with the same version number - how can you tell where the problem is? This is also important for provisioning technology such as p2. If you already have a bundle version 0.8.0 installed or even available in some local repository, p2 will never download the same version over the network. So if a user installs version 0.8.0 build last week, and this week you find a last minute problem and need to produce a different 0.8.1, the installer will ignore the new one because it appears to be the same. I suspect Maven works the same way but I'm not sure. 2) is important because the OSGi resolver, and installers such as p2, will prefer a higher version when presented with multiple versions of a singleton bundle, assuming all other dependencies are equal. Also when searching for updates, p2 by default will only search for higher versions than what is already installed. While it's possible to satisfy the above with three-part versions, it is very difficult. I believe eGit has already produced multiple builds with the 0.8.1 version this release, so these kinds of serviceability and install problems will already be happening. Now, the real question is what do we recommend to people producing OSGi bundles that are being consumed by Maven. I don't know the answer to this, but it seems odd to use the Maven version conventions in the OSGi bundle version, since they actually have different semantics (Maven uses a '-' to separate the qualifier and OSGi uses a '.', among other differences). The bundle version is for consumption by OSGi and should respect its semantics. My initial guess is that the MANIFEST.MF and pom.xml could actually have different version numbers that respect the semantics of OSGi and Maven respectively, but I think you would want build-time support to make sure that's done correctly and consistently. I suspect at this point you should just leave it alone for Helios and come up with a solution for the next release. CCing Pascal who knows a lot more about building OSGi bundles with Maven to see what he suggests. Created attachment 171927 [details]
updated data as of 6/15 9 am eastern
(In reply to comment #3) > Now, the real question is what do we recommend to people producing OSGi bundles > that are being consumed by Maven. I don't know the answer to this, but it seems > odd to use the Maven version conventions in the OSGi bundle version, since they > actually have different semantics (Maven uses a '-' to separate the qualifier > and OSGi uses a '.', among other differences). The bundle version is for > consumption by OSGi and should respect its semantics. My initial guess is that > the MANIFEST.MF and pom.xml could actually have different version numbers that > respect the semantics of OSGi and Maven respectively, but I think you would > want build-time support to make sure that's done correctly and consistently. > > I suspect at this point you should just leave it alone for Helios and come up > with a solution for the next release. CCing Pascal who knows a lot more about > building OSGi bundles with Maven to see what he suggests. Yes, we will discuss that and hopefully find a better solution for the next release 0.9 (planned for September). We will track the progress in bug 310927. I'm just going to use this same bug as an ongoing documentation of the issue of 3 part version numbers. I have not done big check of the whole repo, but in Indigo M6 egit stands out during install as still having one 3 part version numbers. See bug 347241 for the Indigo summary. We did much better. Thanks everyone. |