Hi Mikael
I think you are confused.
Editing e.g. /mdt/downloads/hidden.txt hides a a non-SimRel download ZIP
of a SimRel contribution.
The deferred additiion of e.g.
http://download.eclipse.org/modeling/mdt/ocl/updates/releases/6.3.0
non-composite into the
http://download.eclipse.org/modeling/mdt/ocl/updates/releases composite
similarly hides a non-SimRel copy of a SimRel contribution.
So hiding is about inhibiting project bypasses of the SimRel content
managed by the webmasters. This ensures that the publication by the
webmasters is the first opportunity for an update to find the new
content. (Unless users have explicitly downloaded ZIPs or referenced the
uncomposited release-specific repo.)
---
Suggestions added to https://bugs.eclipse.org/bugs/show_bug.cgi?id=475737
Regards
Ed Willink
On 28/06/2017 14:38, Mickael Istria wrote:
On Wed, Jun 28, 2017 at 3:28 PM, Ed Willink <[email protected]
<mailto:[email protected]>> wrote:
Before the SimRel, it was difficult to establish a coherent set of
plugins for a complex mix of components; e.g. CDT + Sirius.
The SimRel gives a much higher degree of confidence about a
compatible set of versions so that users who ensure that they
stick to a particular release are probably ok. Note how we have
avoided Guava anarchy.
SimRel does test and guarantee that on its own p2 repo, it IMO cannot
and shouldn't target to guarantee that whichever composition of p2
repo leads to compatible solution. Focusing SimRel on the SimRel repo
is already helping a lot and requiring a lot of energy. Most of the
Final Daze actions aren't at all related to the SimRel repo.
The problem occurs at the transition. Hiding makes the version
change atomic. No hiding means that users updating slightly before
SimRel can get some hybrid installations that probably haven't
been tested and we certainly do not want to debug.
In that case, it means that user or that some project deliberately
decided to add a specific p2 repo(s) that in any case goes beyond the
scope of SimRel.
Ditto downloads. It should be possible to register a pattern with
the PMI that renders a nice downloads page. It should be possible
to instruct the PMI to migrate certain pattern elements to archive
so that the downloads page entry points at the archive and the
archive has an index that supports use of the archive. With the
PMI in charge of the downloads page, the PMI could manage hiding
too and update of project repos. Maybe 90% of the activities that
require shell access could be eliminated.
Sounds good. Please open one (or several if it makes more sense) bugs
for PMI.
_______________________________________________
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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
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
