Skip to main content

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


A new thread to focus on the side issue: whether not-hiding is appropriate.

We seem to have three plausible release practices:

a) the hidden until released Final Daze policy - this seems very important for project pairs that produce/consume a new API.

b) the early release policy - e.g. EMF, Xtext - fine when no significant APIs change requiring precise versions

c) the independent release policy - e.g. EGIT - fine when genuinely independent.


Early releases for a very stable +0/+1 component such as EMF may be beneficial since does anyone really care whether they get the new version? Well yes but only if some other component imposes an undesirable tight upper version bound.

Early releases for a +2/+3 component such as Xtext may be beneficial but it mandates that the release support both old and new SimRel APIs.

A late detected bug may require an early release to have a swift +0.0.1 to suit the new SimRel, and perhaps this needs hiding after all.

But is EMF very stable? EMF now has Xcore functionality that introduces a cyclic dependency on Xtext whose very high degree of auto-generation makes pedantic API preservation almost impossible. (Xtext 2.8 to 2.9 was a breaking change that required a Neon and Neon++ release of OCL to accommodate it.) It would seem that an early release of EMF and Xtext and intervening components must be synchronized to ensure that Xcore works.


Is EGIT really independent? Surely any added value such as EGerrit must be coordinated? Perhaps the high release rate ensures that a new API is produced well before it is consumed.


Minor issue. I find it necessary to look at the *.aggrcon to know what is the release/milestone EGIT version or whether the latest Xtext is experimental or contributing. Shouldn't e.g. EGIT have a version change correlating to Simrel? Shouldn't e.g. Xtext's latest version always be contributing? Surely an experimental release should not be on master and not be available for download as a next release?


My conclusion. The not-hiding practices seem like a good idea but fail to avoid real hazards with concurrent introduction of new API production/consumption.


        Ed Willink

On 28/06/2017 06:10, Mickael Istria wrote:
Thanks for sharing this David, it's quite helpful!

On Tue, Jun 27, 2017 at 10:11 PM, David Williams <david_williams@xxxxxxx> wrote:
In many cases, it will work fine if someone updates their composites early, but not necessarily all cases. At least, historically, there have been cases where a user will be told "updates are available" but then when they try to apply them will be told "those updates conflict" with something else they have installed, and then given a list of (possibly confusing) choices (such as, "remove web tools so that emf can be updated?" [to paraphrase, and it is just a hypothetical example]). Perhaps, these days, these mismatches would occur less often than in the past but I suspect not completely and the more projects violated the "Simultaneous" aspect of update sites the more likely users would see issues. That is the core technical reason why there is a Simultaneous Release in the first place.

I agree with you that recent changes in EPP package being made more "modular" make this kind of issues less probable. I also agree that this kind of p2 issues are still possible if users does a mix of multiple p2 sources.
In such case of additional sources being added, we cannot control what's added, so I don't think we're really in the scope of SimRel. Or at least, that this user-story isn't really what we and users are expecting of SimRel (SimRel is a big p2 repo which we know all content work consistently one with the other, nothing more).
Another reason (again, historically) is more mechanical: If some projects (especially large ones) were available for updates early then potentially hundreds of thousands of "update downloads" would be occurring at the same time the mirrors were trying to download gigabits (from other projects) to get fully populated and they would less able to do so. In other words, a network bottleneck: downloads for updates would be slow since there were so few mirrors, and mirrors could not get populated because there were so many downloads.  You can avoid this bottleneck by having bits in place (so mirrors can get them) but to not update the composites until the appointed day (so that users will not be doing mass updates early).

Ok. Do you agree with Ed and I that having projects setting up the mirror when they *release* (typically a few weeks before SimRel release) would prevent this issue from happening?
I am glad when I see efforts made to improve the Sim Rel processes, but I wanted to be sure you kept these factors in mind as you did. These factors tend to be forgotten when they do not occur -- and they have not occurred for many years (I believe) because most projects follow the recommended procedures.

Yes, and thanks for sharing those.
It's a matter of trade-off between the responsibility of a project and the responsibility of SimRel. I think it's also important to make the scope of SimRel clear enough (for example "SimRel builds an aggregated p2 repository of projects conforming to quality guidelines and tested to work together in the same p2 repository") and to see what should remain the responsibility of SimRel (build+test+release of the SimRel repo), what should be the responsibility of individual project release process (p2.mirrorsUrl in individual p2 repos, do not leak p2 repositories as touchpoints or other without informing users), and what should be the responsibility of users (avoid mixing p2 repositories unless they feel like p2 experts)...

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


Back to the top