*** 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]> 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] [
> [email protected]] on behalf of Pascal
> Rapicault [[email protected]]
> Sent: Wednesday, September 23, 2015 3:18 PM
> To: [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]
> 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
>
_______________________________________________
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