go.chromium.org/luci@v0.0.0-20240309015107-7cdc2e660f33/milo/ui/RELEASE_NOTES.md (about) 1 <!-- 2 The release notes are divided by version tags (e.g. `__RELEASE__: 1`) into 3 sections. 4 * The top section without a tag contains unreleased/unannounced changes. This 5 section will not be shown to the users. 6 * The section under the first version tag contains the newest changes. Users 7 will be notified when there's a new release with a release number greater 8 than what they have seen before (stored in local storage). This section will 9 be shown in a notification box. 10 * The sections under the second onward version tags contain past changes. These 11 sections will not be shown in the notification box, but can be viewed in a 12 standalone page. 13 14 Instructions: 15 * Record features: 16 1. Add a feature description to the unreleased section. 17 18 * Create an announcement: 19 1. Add a new release tag with a larger release number at the top of the 20 unreleased section. (The unreleased section is naturally emptied due 21 to the new release tag). 22 2. Once a new release section is created, it should not be modified. 23 Otherwise users may not be notified of the newly added changes. 24 3. Release to prod. 25 26 Design decisions: 27 * The version number is incremental so we won't repeatedly show the release 28 notes after rolling back a release. 29 * We do not use the AppEngine version string (i.e. `VERSION`) because 30 * there might be releases without user facing features, and 31 * it's hard to annotate sections with AppEngine versions since we don't know 32 the AppEngine version at coding time. 33 * The unreleased section is there to avoid confusion about where to add a 34 new feature description. Without it, it's unclear whether a new feature 35 description should be added to a newly created section or an existing 36 section. If the existing section were released to prod, appending to the 37 existing section will fail to announce the feature. If the existing section 38 were not released to prod, adding a new section will cause the features in 39 the existing section to be silenced. Adding an unreleased section makes 40 recording features and creating announcement two separate actions, therefore 41 reduces the confusion. 42 43 TODO: add a test case to ensure the newer release sections always have larger 44 release tag numbers. 45 --> 46 47 <!-- Add new changes here. See the instruction above for more details. --> 48 49 <!-- __RELEASE__: 5 --> 50 ## 2023-11-07 51 [LUCI Analysis](https://luci-analysis.appspot.com) is now using problem-based bug management. 52 53 You will now see a more detailed description of problem(s) a bug has been 54 filed for on the LUCI Analysis rule page and new, more descriptive, bug comments. 55 56 <!-- __RELEASE__: 4 --> 57 <br/><br/><br/> 58 59 # Past releases 60 ## 2023-10-25 61 LUCI is now [finding and bisecting test failures](/ui/p/chromium/bisection/test-analysis). 62 <!-- __RELEASE__: 3 --> 63 If your CL is found to have caused test failures, LUCI may comment on your CL or create a revert CL 64 (but, unlike compile failures, the revert will not be submitted automatically). If you see one of these comments, please investigate and revert or fix your CL. 65 66 You can see all of the bisections that LUCI is performing on the [Bisection Test Analysis page](/ui/p/chromium/bisection/test-analysis). 67 68 (Bisection is currently only running on Chromium. If you want to explore enabling Bisection for your project, please feel free to send feedback from the titlebar) 69 70 <!-- __RELEASE__: 2 --> 71 ## 2023-10-24 72 * Migrated the builder groups page (e.g. [chromium consoles](/ui/p/chromium)) to React. 73 74 <!-- __RELEASE__: 1 --> 75 ## 2023-09-20 76 * A brand new [project selector page](/ui/). 77 * A release notes page. 78 79 <!-- __RELEASE__: 0 --> 80 ## 2023-09-12 81 * A lot of things happened.