[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [epp-dev] Include versus requires/import
- From: Eric Rizzo <eclipse-mail@xxxxxxxxxxxx>
- Date: Wed, 21 Mar 2012 10:02:36 -0400
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=rizzoweb.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=rizzoweb.com; b=XjADNYKBUJVM6eylxf8GShsi6DvAKoZUgJLc8++DBIAia7u8PTfckl1JfsAAR rgkst4rWtObp33ZyUwIZhLRQpT6wE1tDOE7gFdPZJVu+SE4SZmEtIB1Fg8jET6wz /WWbeHrYO5cYrciElBdJwBf4Ybq4i19w8zjnATu+V8Uh8s=
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
On 3/21/12 5:09 AM, Markus Knauer wrote:
There is one subtle difference:
- includes: The feature is bound to a single version and cannot be
upgraded unless the parent feature (EPP) is changed.
- requires: The feature is not upgraded automatically unless the
parent feature (EPP) is changed, but a newer version can be installed
manually into the package (i.e. it is not forbidden to install a
version with a higher version number).
But I like this discussion... my point is that we all need to
understand the difference and that I'd like to have all packages
defined in an equal way.
There's an important Community impact here that I think merits serious
consideration. While "includes" might be more convenient for package
maintainers and releng team, it might produce a product that is
frustrating or impossible for end-users to update piecemeal. I'm not
sure if it will or won't, but want the package maintainers to know :-)
There are several common scenarios that I think we need to make sure
will work smoothly for users:
A) I download an EPP package initial release. Later SR1 or SR2 is
released and I want to easily update to that release of the same package
I originally installed. I'm pretty sure this is tested already, correct?
B) I download an EPP package, for example Eclipse for Java Developers.
Later I realize that I want some other set of features, such as
features/plugins I want depends on a version of something in my original
package that is newer than what the package originally included. For
example, version 25.3 of ECore Tools depends on version 19.3.5 of JFace,
but my EPP package included JFace version 19.3.0. I should be able to do
this update smoothly without all of p2's confusing and overwhelming
"cannot satisfy dependency" errors.
C) I downloaded an EPP package initial release, but later want to update
one of the components of that package from it's project's own update
site (maybe a critical bug fix in between SRs, whatever). Again, I
should b able to do that update smoothly and easily.
Since the EPP packages are what most users get (by a large margin), I
think we should be careful to avoid making those packages difficult to
update or add on to. At the very least those three scenarios should work
smoothly. There might be more I haven't though of.