> 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
---
However I'm not sure I got the details.
The URL 'updates/v6' was intended to remain valid as long as the version remains 6.x (the plug-ins remain compatible), while 'releases/6.0' would be valid only for 6.0.x, and will be later followed by `releases/6.1' and so on, so those who have 6.0 installed will no longer get updates.
So, if we stick to 'updates/v6', all future releases will accumulate there, and there may be lots of them. Is this a problem?
Another solution would be to keep 'updates/v6' with the latest release, as of now, and have multiple 'releases/6.0', 'releases/6.1', etc as composite sites. But this means the users have to manually configure one of these URLs to access previous versions. How would users know these URLs? This seems quite complicated.
---
Assuming we make 'updates/v6' composite, the publish procedure would be:
- publish the actual release to a new folder like 'releases/6.0.0', 'releases/6.0.01', etc
- update the two magic file to include the new folder
- copy the two files to 'updates/v6'
Is this correct? Should 'updates/v6' include anything else apart from these two files?
That is correct.
Nothing else needed in updates/v6.
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.
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.
HTH
Jonah
Regards,
Liviu
_______________________________________________
embed-cdt-dev mailing list
embed-cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/embed-cdt-dev
