From 4e93b135a8d5b61ba64ded6a3e1a76ae9708d9bd Mon Sep 17 00:00:00 2001 From: nisfeb Date: Wed, 8 Apr 2026 21:03:17 -0400 Subject: [PATCH 1/3] uip-0137: merge window closing notice requirement Add Process UIP requiring minimum four weeks notice before any merge window closes, announced at Core Architecture meetings. Includes exceptions for CVEs, critical bugs, and security dependency uplifts. --- README.md | 1 + UIPS/UIP-0137.md | 70 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 UIPS/UIP-0137.md diff --git a/README.md b/README.md index c58a5b2..43fb5d0 100644 --- a/README.md +++ b/README.md @@ -55,6 +55,7 @@ UIPs can be divided into the following categories: | [0134](./UIPS/UIP-0134.md) | Subsecond Timing Syntax | ~lagrev-nocfep | Approved | Standards | | [0135](./UIPS/UIP-0135.md) | Adjust @da format | ~palfun-foslup | Approved | Standards | | [0136](./UIPS/UIP-0136.md) | Comet Attestation | ~hanfel-dovned, ~tinnus-napbus, ~bonbud-macryg, ~tondes-sitrym | Review | Standards | +| [0137](./UIPS/UIP-0137.md) | Merge Window Closing Notice Requirement | ~nisfeb | Draft | Process | ## Background diff --git a/UIPS/UIP-0137.md b/UIPS/UIP-0137.md new file mode 100644 index 0000000..7efc4dc --- /dev/null +++ b/UIPS/UIP-0137.md @@ -0,0 +1,70 @@ +--- +uip: "0137" +title: Merge Window Closing Notice Requirement +description: Requires minimum four weeks notice before any merge window closes, announced at Core Architecture meetings. +author: ~nisfeb (@nisfeb) +status: Draft +type: Process +created: 2026-04-08 +--- + +## Abstract + +This UIP establishes a minimum notice requirement of four weeks before any merge window closes for an Urbit release. The notice MUST be given at a Core Architecture meeting of the Core Guild, which convenes monthly. This ensures that developers have adequate time to finalize and submit work targeting a given release. + +## Motivation + +Currently, there is no formal requirement for how much advance notice developers receive before a merge window closes. This can result in situations where contributors are caught off guard by a closing window, leading to rushed submissions, deferred work, or missed releases entirely. Since the Core Architecture meeting is the primary coordination point for core development and occurs on a monthly cadence, it is the natural venue for such announcements. A four-week minimum aligns with the monthly meeting schedule and gives developers at least one full meeting cycle to respond. + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +1. Before any merge window is closed for a release, the Core Guild MUST provide a minimum of four (4) calendar weeks of notice to the developer community. + +2. The notice MUST be announced at a Core Architecture meeting. The meeting at which the announcement is made starts the four-week clock. + +3. The notice SHOULD include: + - The target date for the merge window closing. + - The release or kelvin version the window applies to. + - Any UIPs or work items expected to land in the release. + +4. If the merge window close date changes after the initial announcement, a new four-week notice period MUST begin from the meeting at which the revised date is announced, unless the change extends the window (i.e., pushes the close date further out). + +5. The merge window MUST NOT close earlier than four weeks from the most recent announcement of its close date at a Core Architecture meeting. + +6. This process applies to all releases, including kelvin decrements, non-kelvin OTAs, and any other release that involves a merge window. + +7. The following categories of releases are EXEMPT from the four-week notice requirement: + - **Security fixes**: Releases that address CVEs, actively exploited vulnerabilities, or other security issues where delayed deployment would put the network or its users at risk. + - **Critical bug fixes**: Releases that fix bugs causing data loss, ship bricking, network partitions, or other severe operational failures. + - **Dependency uplifts for security**: Updates to third-party dependencies driven by upstream security advisories. + +8. When an exempt release is made without the standard four-week notice, the Core Guild MUST provide a retrospective explanation at the next Core Architecture meeting, including: + - The nature of the issue that triggered the exception. + - Why the standard notice period could not be observed. + - What was included in the release beyond the exempt fix, if anything. + +9. Exempt releases SHOULD be scoped narrowly to the issue justifying the exception. Non-critical changes SHOULD NOT be bundled into an exempt release to bypass the notice requirement. + +## Rationale + +Four weeks was chosen because it aligns with the monthly cadence of Core Architecture meetings. A shorter period (e.g., two weeks) would risk the announcement falling between meetings, meaning some developers might not hear about it through the primary coordination channel. A longer period (e.g., eight weeks) would slow down the release process unnecessarily. + +Requiring announcement at Core Architecture meetings rather than through informal channels (e.g., group chat) ensures there is a well-defined, auditable moment when notice is given. The meeting format also allows for immediate Q&A and coordination. + +The provision for resetting the clock when a window is moved earlier prevents the notice requirement from being circumvented by initially announcing a later date and then moving it up. + +Exceptions for security fixes, critical bugs, and security-driven dependency uplifts are necessary because rigid adherence to a four-week window in those cases would leave the network exposed to known threats. The retrospective requirement ensures these exceptions are not abused — the Core Guild must publicly account for any release that bypasses the standard process. The narrow-scoping provision (item 9) prevents unrelated changes from being bundled into an emergency release as a way to skip the notice period. + +## Backwards Compatibility + +This is a process change and does not affect any software interfaces. Existing release procedures would need to incorporate the notice requirement going forward. Any merge window that is already open at the time this UIP is adopted SHOULD be given a four-week notice from the next Core Architecture meeting before closing. + +## Security Considerations + +Needs discussion. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 1325fd82ebff4eb619e5b1b05569346bdf859179 Mon Sep 17 00:00:00 2001 From: nisfeb Date: Wed, 8 Apr 2026 21:12:11 -0400 Subject: [PATCH 2/3] update language --- UIPS/UIP-0137.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/UIPS/UIP-0137.md b/UIPS/UIP-0137.md index 7efc4dc..bc7998d 100644 --- a/UIPS/UIP-0137.md +++ b/UIPS/UIP-0137.md @@ -29,9 +29,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S - The release or kelvin version the window applies to. - Any UIPs or work items expected to land in the release. -4. If the merge window close date changes after the initial announcement, a new four-week notice period MUST begin from the meeting at which the revised date is announced, unless the change extends the window (i.e., pushes the close date further out). +4. The merge window MUST NOT close earlier than four weeks from the most recent announcement of its close date at a Core Architecture meeting. -5. The merge window MUST NOT close earlier than four weeks from the most recent announcement of its close date at a Core Architecture meeting. +5. If the merge window is extended, the new close date SHOULD be announced at the next Core Architecture meeting. 6. This process applies to all releases, including kelvin decrements, non-kelvin OTAs, and any other release that involves a merge window. @@ -53,8 +53,6 @@ Four weeks was chosen because it aligns with the monthly cadence of Core Archite Requiring announcement at Core Architecture meetings rather than through informal channels (e.g., group chat) ensures there is a well-defined, auditable moment when notice is given. The meeting format also allows for immediate Q&A and coordination. -The provision for resetting the clock when a window is moved earlier prevents the notice requirement from being circumvented by initially announcing a later date and then moving it up. - Exceptions for security fixes, critical bugs, and security-driven dependency uplifts are necessary because rigid adherence to a four-week window in those cases would leave the network exposed to known threats. The retrospective requirement ensures these exceptions are not abused — the Core Guild must publicly account for any release that bypasses the standard process. The narrow-scoping provision (item 9) prevents unrelated changes from being bundled into an emergency release as a way to skip the notice period. ## Backwards Compatibility From 7164543eb09890c83245e34750a42a936d69aa70 Mon Sep 17 00:00:00 2001 From: ~nisfeb <78994617+nisfeb@users.noreply.github.com> Date: Wed, 8 Apr 2026 22:23:01 -0400 Subject: [PATCH 3/3] Update UIP-0137.md --- UIPS/UIP-0137.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UIPS/UIP-0137.md b/UIPS/UIP-0137.md index bc7998d..e1de8fd 100644 --- a/UIPS/UIP-0137.md +++ b/UIPS/UIP-0137.md @@ -53,7 +53,7 @@ Four weeks was chosen because it aligns with the monthly cadence of Core Archite Requiring announcement at Core Architecture meetings rather than through informal channels (e.g., group chat) ensures there is a well-defined, auditable moment when notice is given. The meeting format also allows for immediate Q&A and coordination. -Exceptions for security fixes, critical bugs, and security-driven dependency uplifts are necessary because rigid adherence to a four-week window in those cases would leave the network exposed to known threats. The retrospective requirement ensures these exceptions are not abused — the Core Guild must publicly account for any release that bypasses the standard process. The narrow-scoping provision (item 9) prevents unrelated changes from being bundled into an emergency release as a way to skip the notice period. +Exceptions for security fixes, critical bugs, and security-driven dependency uplifts are necessary because rigid adherence to a four-week window in those cases would leave the network exposed to known threats. The retrospective requirement ensures these exceptions are not abused. The narrow-scoping provision (item 9) prevents unrelated changes from being bundled into an emergency release as a way to skip the notice period. ## Backwards Compatibility