|Re: [cross-project-issues-dev] [Brainstorming] Why (not) a "Final Daze" in SimRel?|
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.
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).
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.