Skip to content

Update development practices #734

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 28, 2025
+8 −5
Merged

Update development practices #734

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions docs/contributing.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand Down Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
know that a release is planned. At least a week's notice should be given for other
know that a release is planned. In most cases, at least a week's notice should be given for other

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm reluctant to un-tighten the language here - I think for minor releases (as opposed to micro releases with bugfixes) a week's notice is reasonable?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find these sorts of black/white constraints to introduce unnecessary friction. We don't want to get into a place where a minor release needs to go out but someone objects to its release because the announcement was only 5 days prior. I'm looking for directional guidance here, not hard and fast rules.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "should be given" already indicates that almost always it should be respected, but there's room in exceptional circumstances to bypass the reccomendation? At least that's the existing language in this document, and it's not prefaced by "in most cases" elsewhere.

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.
Expand Down
Loading