From c47e8bf5d5eb63c55ab2482cd62ec06c64049f39 Mon Sep 17 00:00:00 2001 From: David Stansby Date: Tue, 8 Apr 2025 10:01:41 +0100 Subject: [PATCH] Update development practices --- docs/contributing.rst | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/docs/contributing.rst b/docs/contributing.rst index e5cd936ea..5bfff5184 100644 --- a/docs/contributing.rst +++ b/docs/contributing.rst @@ -203,12 +203,11 @@ contributors. Merging pull requests ~~~~~~~~~~~~~~~~~~~~~ -Pull requests submitted by an external contributor should be reviewed and approved by at least -one core developers before being merged. Ideally, pull requests submitted by a core developer -should be reviewed and approved by at least one other core developers before being merged. +Pull requests should be reviewed and approved by at least one core developer +(other than the pull request author) before being merged. -Pull requests should not be merged until all CI checks have passed (Travis, AppVeyor, -Codecov) against code that has had the latest main merged in. +Pull requests should not be merged until all CI checks have passed against code +that has had the latest main merged in. Compatibility and versioning policies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -278,6 +277,10 @@ hard-and-fast rules, e.g., it is fine to make a minor release to make a single n feature available; equally, it is fine to make a minor release that includes a number of changes. +When making a minor release, open an issue stating your intention so other developers +know that a release is planned. At least a week's notice should be given for other +developers to be aware of and possibly add to the contents of the release. + Major releases obviously need to be given careful consideration, and should be done as infrequently as possible, as they will break existing code and/or affect data compatibility in some way.