As I wrote in my earlier mail: The RCP/RAP package installs *all* features
as root features, all other packages have only a single root feature
defined by EPP. There's no version restriction involved or enforced.


Regards,
Markus

On 23 September 2015 at 22:24, Max Rydahl Andersen <[email protected]>
wrote:

> I believe EPP in their features can be less restrictive and allow for
> version ranges in what the root feature will allow.
>
> Maybe that is what the RCP EPP package do ?
>
> If yes,then I can tell that is how we for Developer Studio allow updates
> of certain features (like egit and m2e) to avoid having to release the main
> feature all the time.
>
> /max
>
> Ah, that's it. Perfect. Thanks Markus!
>>
>> IMHO, we should make this mandatory for all packages and have someone
>> just go in and do it.
>>
>> Doug.
>>
>> ________________________________
>> From: [email protected] [
>> [email protected]] on behalf of Markus Knauer
>> [[email protected]]
>> Sent: Wednesday, September 23, 2015 3:44 PM
>> To: Cross project issues
>> Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was Re:
>> Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)
>>
>> *** Automatically check for updates:
>>
>> That's enabled in all packages, and all of them are looking for updates
>> of their root feature(s) once every week.
>>
>> *** Package structure:
>>
>> All Mars packages (with the exception of the RCP/RAP package) are using a
>> single root feature that is checked for a higher version. This root feature
>> is an EPP feature and controlled by the package maintainers. In theory it
>> could be updated and the respective package would be updated with the new
>> content. Of course, this works only if the update content is available from
>> one of the p2 repositories built into the packages (which is the
>> Simultaneous Release p2 repository).
>>
>> The RCP/RAP package structure has changed with Mars, as an experiment in
>> order to get some experience and as a way to "convince" others in the Neon
>> timeframe to change the package structure of the remaining packages. In
>> this package *all* content features are installed as root features and
>> therefore checked for updates.
>>
>> Personally I think that's the way to go for all packages. The fact that
>> it is enabled in RCP/RAP gives us a chance to get some experience in order
>> to roll it out for all packages in the Neon timeframe.
>>
>> Regards,
>> Markus
>>
>>
>> On 23 September 2015 at 21:31, Doug Schaefer <[email protected]<mailto:
>> [email protected]>> wrote:
>> Step 1 - test to see whether it works. Anecdotal evidence says it
>> doesn't. Something about how the EPP packages are defined and built. Also
>> projects need to make sure the URLs for maintenance p2 sites are correct
>> and enabled by default.
>>
>> The Check for Updates including the auto check feature itself works.
>> We've used it for years in our commercial product. Just need to make sure
>> everything is set up correctly for the packages.
>>
>> I'm also not sure (and actually doubt) auto check is turned on in all the
>> packages so that when users start them up and/or on regular intervals it
>> does a check and prompts the user to install the updates.
>>
>> This has to be the default behavior without the user having to do
>> anything. That way the user could have installed Mars.1 and then when they
>> start up they would have been prompted to install the update for Buildship
>> any other feature that happened to have updates out by then.
>>
>> We talked about this at the architecture call. Not sure it got captured
>> in the minutes there. But this is the general idea.
>>
>> Doug.
>>
>>
>> ________________________________________
>> From: [email protected]<mailto:
>> [email protected]> [
>> [email protected]<mailto:
>> [email protected]>] on behalf of Pascal
>> Rapicault [[email protected]<mailto:[email protected]>]
>> Sent: Wednesday, September 23, 2015 3:18 PM
>> To: [email protected]<mailto:
>> [email protected]>
>> Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was Re:
>> Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)
>>
>> I was about to ask the same :)
>>
>> On 15-09-23 02:54 PM, Mike Milinkovich wrote:
>>
>>> On 23/09/2015 1:49 PM, Doug Schaefer wrote:
>>>
>>>> if we could ever get Check for Updates working properly, this
>>>> wouldn't have been such a big issue.
>>>>
>>>
>>> Doug (or anyone)
>>>
>>> Is there a written proposal anywhere on how "Check for Updates" should
>>> be modified?
>>>
>>> Is there an existing consensus around such a proposal?
>>>
>>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> [email protected]<mailto:
>> [email protected]>
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> [email protected]<mailto:
>> [email protected]>
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> [email protected]
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> /max
> http://about.me/maxandersen
>
> _______________________________________________
> cross-project-issues-dev mailing list
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to