Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [embed-cdt-dev] Until and unless a new composite is provided the upgrade feature won't be available

> On 30 Nov 2020, at 23:10, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
> ~~~
> Jonah Graham
> Kichwa Coders
> On Mon, 30 Nov 2020 at 15:38, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:
> > On 30 Nov 2020, at 22:11, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
> > 
> > Well in that case you can just make the /update/v6 the composite instead of releases/6.0.
> Hmmm... I was just preparing SimRel for 2020-12-rc1.
> Can we do this in rc2?
> Yes. 
> Wed 5pm Ottawa time is deadline for Simrel changes
> Thu 9am Ottawa time is deadline for EPP changes

Ok, thank you for these details, I copied them in my file to avoid asking them again and again :-)

> p2 repos for end users should not have changing content, i.e. it is bad to update a non-composite p2 repo that an end user has as it affects things such as uninstalling and rolling back installations.

Aha. Good point. I somehow expected such a problem, all my old update sites stored at were non-composite and I copied the entire content in the same folder, so with time I got a big mess.

> To answer the "updates/v6" vs "releases/6.0" - it depends as to what we want to push as updates to users. For CDT we only push service releases, not minor releases, hence the URL is 10.0. The 10.0 composite won't update a user to 10.1.0.
> However you are best placed to know how updates should be rolled out to users.

Apart from the mess with non-composite changing sites, I used the same update url since Eclipse Neon, and users got used to always get the latest available version from there.

Starting with v6.0.0 I thought that it would be ok to change the url to updates/v6, and keep it fixed as long as the plug-ins remain compatible.

If the potential large number of versions behind this composite site will not be a problem, I would keep it like this.

BTW, 'updates/v6' is already configured in the source files, so continuing to use it would requires no further changes, only to the publish procedure, which should copy the two files.



Back to the top