Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox/p2/Omni Version"
(→Background) |
|||
| Line 1: | Line 1: | ||
=Introduction= | =Introduction= | ||
This page describes a proposal for adding support for non OSGi version and version ranges in Equinox p2. This page was created as a result of the discussion on the p2 call on Dec 1, 2008. | This page describes a proposal for adding support for non OSGi version and version ranges in Equinox p2. This page was created as a result of the discussion on the p2 call on Dec 1, 2008. | ||
| − | =Background= | + | ==Background== |
There are other versioning schemes in wide use that are not compatible with OSGi version and version ranges. The problem is both syntactic and semantic. | There are other versioning schemes in wide use that are not compatible with OSGi version and version ranges. The problem is both syntactic and semantic. | ||
| Line 23: | Line 23: | ||
These are not syntactically compatible with OSGi versions as they use colon, and dash as leading separators. | These are not syntactically compatible with OSGi versions as they use colon, and dash as leading separators. | ||
| + | ==Current implementation in p2== | ||
| + | The current implementation in p2 uses the classes Version and Version range to describe the two concepts and these are implementations handling only OSGi version type. | ||
| + | |||
| + | =Proposed Solution= | ||
| + | Equinox p2 should support a set of "built in" version types. After a lengthy discussion about various "chicken and egg" type of problems relating to dynamic version type specifications and when and how the need for a particular version type is detected, and when it needs to be installed the meeting came to the conclusion that support for a "handful of built in types" would be sufficient as a starting point. | ||
| + | |||
[[Category:Equinox p2|Touchpoint Instructions]] | [[Category:Equinox p2|Touchpoint Instructions]] | ||
Revision as of 18:07, 1 December 2008
Contents
Introduction
This page describes a proposal for adding support for non OSGi version and version ranges in Equinox p2. This page was created as a result of the discussion on the p2 call on Dec 1, 2008.
Background
There are other versioning schemes in wide use that are not compatible with OSGi version and version ranges. The problem is both syntactic and semantic.
Example of semantic issue
Many open source projects do their versioning in a fashion similar to OSGi but with one very significant difference. For two versions that are otherwise equal, a lack of qualifier signifies a higher version then when a qualifier is present. I.e.
1.0.0.alpha 1.0.0.beta 1.0.0.rc1 1.0.0
The 1.0.0 is the final release. The qualifier happens to be in alphabetical order here but that's not always true.
Example of syntax issue
Here are some examples of versions used in Red Had Fedora distributions.
KDE Admin version 7:4.0.3-3.fc9 Compat libstdc version 33-3.2.3-63 Automake 1.4p6-15.fc7
These are not syntactically compatible with OSGi versions as they use colon, and dash as leading separators.
Current implementation in p2
The current implementation in p2 uses the classes Version and Version range to describe the two concepts and these are implementations handling only OSGi version type.
Proposed Solution
Equinox p2 should support a set of "built in" version types. After a lengthy discussion about various "chicken and egg" type of problems relating to dynamic version type specifications and when and how the need for a particular version type is detected, and when it needs to be installed the meeting came to the conclusion that support for a "handful of built in types" would be sufficient as a starting point.