[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [epp-dev] Include versus requires/import
- From: Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
- Date: Wed, 21 Mar 2012 15:34:06 +0100
- Delivered-to: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclipsesource.com; s=eclipsesource; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=caIHf4Zn5UOFCYX9k/XSDuaWJycJke88q4uGpkjhWUw=; b=agz61t+Ct2VHHvqx+WJjBXqII++8VbY5cxHSm6oH2GeIgrHnI8/A0d9zMtG6Qe8fAY lqRRfmNHM/Un0yNBdTGRzzr7dJKLeSzFcKHd2lJQLTZLodCE4Zan7oy+2vDUWPryTIFM hjRRS0eqYlMNEFoj7NTnmj4083dBFCkk7dcnE=
I completely agree.
A) (update R->SR1->SR2) is tested and would be supported by both, includes and requires
B) and C) only possible with 'requires' but not with 'includes'
D) That's a new one and I think it is worth adding it to the list: Automated updates. If a project A is part of a package, it is a child of the package feature. If project A releases a new version with bugfixes on their p2 repository, there is no automated update of the package content possible unless (a) the package feature is updated or (b) the user manually installs the features from project A as root features into the package.
On Wed, Mar 21, 2012 at 15:02, Eric Rizzo <eclipse-mail@xxxxxxxxxxxx>
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 :-)
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 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?
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.