| Hi, I have updated the proposal with a section called "applicability" to describe where generalization is needed.
What is the segment delimiter for the "any" version type?
The "any" type does not define the segment delimiter - the delimiters are specified by the defined types - as an example raw(%d:%d) defines two numerical segments with a ":" as delimiter. The only "delimiters" are the version range delimiters, but an any type string is not allowed to include them unescaped.
What kinds of methods will be on IVersion and IVersionRange? We currently have code in various places that does range manipulations such as union and intersection, which would become more complicated in this world and would benefit from helper methods. Of course something like VersionRange.isIncluded(Version) would also be needed.
A helper class that does range manipulations like "union" that is capable of handling comparison across types and "any" sound like a good approach. I did not look at current methods and use as I wanted to get feedback on the general approach first.
We currently invoked the OSGi resolver in a couple of places (attaching fragments, computing explanations in case of failure, see ResolutionHelper). How will this deal with different version schemes?
Good question. If the implementation that handles fragments requires OSGi type versions, then that would need to be a restriction at the highest level. Does this matter? I am not aware of how the explanations are produced by OSGi resolver - so have no regarding that.
Performance is obviously a potential concern for the pattern-based scheme. We would need to know if this will scale to thousands or tens of thousands of IUs.
Agree. Care is needed - raw versions should be lazily transformed and cached. The suggested pattern matching rules should be reasonably fast to compute.
On Dec 3, 2008, at 7:48 PM, John Arthorne wrote:
Hi Henrik,
The proposal looks good - well thought out and staged. Some questions/comments:
We use Version/VersionRange in many different places in p2, so it would be good to clarify where this generalization is needed. Obviously you are interested in IInstallableUnit/RequiredCapability/ProvidedCapability, but there are many other areas as well:
- File format version numbers (content.xml, artifact.xml, etc)
- UpdateDescriptor
- Touchpoint version numbers and touchpoint action versions
- Publisher advice versions
- Artifact key versions
I suspect many of these other uses wouldn't stand to benefit much from moving to generic version types, but it's worth clarifying the scope of the proposed changes.
What is the segment delimiter for the "any" version type?
What kinds of methods will be on IVersion and IVersionRange? We currently have code in various places that does range manipulations such as union and intersection, which would become more complicated in this world and would benefit from helper methods. Of course something like VersionRange.isIncluded(Version) would also be needed.
We currently invoked the OSGi resolver in a couple of places (attaching fragments, computing explanations in case of failure, see ResolutionHelper). How will this deal with different version schemes?
Performance is obviously a potential concern for the pattern-based scheme. We would need to know if this will scale to thousands or tens of thousands of IUs.
John
Hi, in the p2 call on December 1, I promised to write a detailed
proposal for handling non osgi versions in p2.
The first revision of the proposal is now ready on the wiki at http://wiki.eclipse.org/Equinox/p2/Proposals/Version_Type_Proposal
Regards
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|
