From ea79fbc2e0e1bd93d3264a4b0e76c152b4e69591 Mon Sep 17 00:00:00 2001 From: Moody Salem Date: Tue, 20 Jul 2021 16:10:58 -0500 Subject: [PATCH] chore: add blurb about release process (#2061) * chore: add blurb about release process * additional standard * how to collect feedback --- CONTRIBUTING.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 53cbcbce2..29aefb30e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,3 +1,4 @@ + # Contributing Thank you for your interest in contributing to the Uniswap interface! 🦄 @@ -23,6 +24,7 @@ makes large architectural changes, consider following all the standards. - Have at least one engineer approve of large code refactorings - At least manually test small code changes, prefer automated tests - Thoroughly unit test when code is not obviously correct +- If something breaks, add automated tests so it doesn't break again - Add integration tests for new pages or flows - Verify that all CI checks pass before merging - Have at least one product manager or designer approve of significant UX changes @@ -42,6 +44,20 @@ The following points should help guide your development: - Accessibility: anyone can use the interface - The interface should be responsive, small and run well on low performance devices (majority of swaps on mobile!) +## Release process + +Releases are cut automatically from the `main` branch Monday-Thursday in the morning according to the [release workflow](./.github/workflows/release.yaml). + +Fix pull requests should be merged whenever ready and tested. +If a fix is urgently needed in production, releases can be manually triggered on [GitHub](https://github.com/Uniswap/uniswap-interface/actions/workflows/release.yaml) +after the fix is merged into `main`. + +Features should not be merged into `main` until they are ready for users. +When building larger features or collaborating with other developers, create a new branch from `main` to track its development. +Use the automatic Vercel preview for sharing the feature to collect feedback. +When the feature is ready for review, create a new pull request from the feature branch into `main` and request reviews from +the appropriate UX reviewers (PMs or designers). + ## Finding a first issue Start with issues with the label