Re: [cross-project-issues-dev] Component release hiding (was Re: [Brains

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

You assume an undue degree of perfection in releng's. Lower bounds are generally pretty inaccurate, particularly if they reflect an underlying semantic rather than source incompatibility.

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.

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.

I agree that the current manual Daze activities deserve to be automated, especially the XML mirror properties. One year I had an &quot; typo. No diagnosis. It was a few years before I spotted that size=3 probably needed to increase to size=5 to accommodate the two new properties. Again no diagnosis. I'm lucky that my releng predecessor wrote a shell script to rename RCx ZIPs and recompute their hashes.

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.

    Regards

        Ed Willink

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

If projects do not hide their releases, it can be easy to accidentally upgrade one component without updating another

Ok, got it. However, I'm still convinced that a "hiding" policy is not a viable solution for this problem. The solution is proper OSGi version numbering, which scales independently of how p2 repositories are deployed.

And since many people don't update to SimRel on the day of the release, this transient state of older SimRel version with newer components visible is affecting all those users already, even with a "hide" strategy.

So hiding isn't a sustainable solution for this issue IMO, so that it'd better being dropped from the requirement/process to make things simpler for everyone and drive projects to find real solutions if they suffer from such versioning issues.

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Virus-free. www.avast.com