Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Component release hiding (was Re: [Brainstorming] Why (not) a "Final Daze" in SimRel?)

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. non-composite into the 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


        Ed Willink

On 28/06/2017 14:38, Mickael Istria wrote:

On Wed, Jun 28, 2017 at 3:28 PM, Ed Willink <ed@xxxxxxxxxxxxx> 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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


Back to the top