Re: [p2-dev] Versions that are not OSGi compliant

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Pascal,
Pascal Rapicault wrote:

I'm mixed about this, mostly because I'm not convinced that canonicalization does not work (do you have examples)

The tricky thing is to preserve version range semantics. In order to do that, the canonicalization needs to preserve the lexical ordering of versions so you need explicit knowledge about how the version is constituted. I'm not arguing that canonicalization is impossible. It would however not in any way remove the need for explicit handling of each type of version that is subject to it so it doesn't solve the general problem. The way I see it, that in itself makes canonicalization a less attractive choice. What benefits does it bring other then transforming valid and well known versions into something that the user will be very unfamiliar with? And what mechanism would be used to extend it?

I sent out some examples in my previous mail that I think illustrates the need for explicit handling of different types of versions.

and because of the breadth of the code change.
Also, here are a few questions that comes to mind:
- What happen when the "version handler" is not around?

The resolver must treat the version types as prerequisites on its environment. IU's that use types that are not around are incompatible with the current environment. The user must install something more in order to make use of such IU's.

- Can't we come up with a rule based approach to avoid everyone to have to provide their version handler class?

I think we could come up with a limited set of version types that would cover the majority of cases. You have the OSGi type already. We have a type that we call Triplet that is similar but it's different in that it treats the lack of a qualifier as a higher version and it allows for 1, 2, or 3 digits in the number. We can talk to other major players (guys behind Linux distros for instance) about other commonly used version schemes. I'm pretty sure that we would be very well covered with 4-6 different types. Then, if other companies have other very special requirements, they must provide something that extend our framework. I don't see that as a big deal.

Let's discuss this at the next p2 call: http://wiki.eclipse.org/Equinox/p2/Meetings/20081117

At what time is the call?

Regards,
Thomas Hallgren

PaScaL

Thomas Hallgren ---11/11/2008 11:51:44 AM---Hi, A while back I brought up the discussion about versions that are not

From:	Thomas Hallgren <thomas@xxxxxxx>
To:	P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:	11/11/2008 11:51 AM
Subject:	[p2-dev] Versions that are not OSGi compliant

---

Hi,
A while back I brought up the discussion about versions that are not
compliant with the standard OSGi format. A brief discussion with Pascal
can be viewed here:

http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04260.html

I also entered a bugzilla

https://bugs.eclipse.org/bugs/show_bug.cgi?id=233699

This issue important to us and as we're moving our technology closer to
P2 we would really like to see a resolution. We are of course willing to
contribute, partly or in full, if that's what it takes. We have good
ideas of how this can be done without any impact on resolution
performance. The thing missing at this point is some enthusiastic
responses from the p2 team :-)

So what do you think?

Regards,
Thomas Hallgren

_______________________________________________
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