Hi Pascal,
I though I just did. I'm available any time except between noon to 4PM
EST.
- thomas
Pascal Rapicault wrote:
Let us know when you are available and we can schedule a special
call to discuss this issue.
 Thomas
Hallgren ---18/11/2008 06:28:29 AM---Hi Pascal, Yes, I was really sorry
about not being able to participate. My sincere apologies. I had
Hi Pascal,
Yes, I was really sorry about not being able to participate. My sincere
apologies. I had other rather pressing engagements at that precise
time. My schedule is flexible but I try to keep the time between 6pm
and 10pm free from work (I'm in Stockholm so that's noon to 4pm EST).
Any other time is fine by me.
Regards,
Thomas Hallgren
Pascal Rapicault wrote:
Since you could not make it to the call (sorry for
the short notice), we postponed the call to a later date. Please let us
know when you can join.
Note that we are in the process of rescheduling our calls to Monday's
at 3 PM EDT.
PaScaL
 Thomas Hallgren
---15/11/2008 11:38:03 AM---Hi Pascal, Pascal Rapicault wrote: I'm
mixed about this, mostly because I'm not convinced that can
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.
At what time is the call?
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
_______________________________________________
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
|
