The release date for the respective UMD release is fixated to the then set date. Before the release freeze date, the release date (and all dependent timeline dates) may change. While in theory this may mean that one can delay a given UMD release indefinitely, in practice that has never happened so far.

Any product in the Software Provisioning process that did *not* get accepted by StagedRollout by that day, will be pushed to the subsequent UMD release (or perhaps even later as required). Technically, at that day, all products with an RT ticket in state "UMDStore" in the "sw-rel" queue will be taken into the UMD Composer, all at once. (see below)

The products that made the cut-off date will be taken into the next UMD release in the UMD Composer. Verification and StagedRollout assemble the necessary documentation, such as Konwn issues, Installation notes, etc. for the release's Wiki page, and summaries for the UMD release itself that will be published in the repository later-on. 2 days are seen enough, particularly when the relevant information is pre-assembled in a temporary Wiki space etc.

At least one Release Candidate (RC) will be prepared for the currently provisioned UMD release including all accepted products.

• EA sites that participated in the provisioning of this UMD release are approached to test this RC.
• All StagedRollout EA sites are also invited to test this RC.
• If the current RC is unacceptable, then another RC may be produced correcting the issues. This may affect the actual final release date, and is decided on a case-by-case basis.
• If no more feedback is given for the current RC, then this RC will become the final release of the provisioned UMD release.

The UMD release is published for production. The aim is to publish UMD releases on a Monday, or in the first half of the week up to and including Wednesdays.