From a3f4cb4aa76b88ff3f1ad4696fe9ebf00e9f8e33 Mon Sep 17 00:00:00 2001 From: Tyler Neely Date: Sat, 13 Oct 2018 09:56:22 +0200 Subject: [PATCH 1/3] Create MAINTAINERSHIP.md --- MAINTAINERSHIP.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 MAINTAINERSHIP.md diff --git a/MAINTAINERSHIP.md b/MAINTAINERSHIP.md new file mode 100644 index 0000000..5095a75 --- /dev/null +++ b/MAINTAINERSHIP.md @@ -0,0 +1,42 @@ +Maintainers agree to operate under this set of guidelines: + +#### Authority + +Maintainers are trusted to close issues, merge pull requests, and publish crates to cargo. + +#### Categories of Work + +0. Minor + * updating the changelog + * requires no approval +1. Normal + * librocksdb-sys updates + * API tracking code in the rocksdb crate that does not change control flow + * breaking changes due to removed functionality in rocksdb + * require 1 approval from another maintainer. if no maintainer is able to be reached for 2 weeks, then progress may be made anyway + * patch (and post-1.0, minor) releases to crates.io that contain only the above work +2. Major + * breaking API changes that are not direct consequences of underlying rocksdb changes + * refactoring, which should generally only be done for clearly functional reasons like to aid in the completion of a specific task + * require consensus among all maintainers unless 2 weeks have gone by without full participation + * if 2 weeks have gone by after seeking feedback, and at least one other maintainer has participated, and all participating maintainers are in agreement, then progress may be made anyway + * if action is absolutely urgent, an organization owner may act as a tiebreaker if specifically requested to do so and they agree that making a controversial decision is worth the risk. This should hopefully never occur. + +If any maintainer thinks an issue is major, it is major. + +#### Changelog Maintenance + +* If you are the one who merges a PR that includes an externally-visible change, please describe the change in the changelog and merge it in. + +#### Releasing, Publishing + +* To cut a release, an issue should be opened for it and reach the required approval based on the above `Categories of Work` section above +* When progress is possible, the issue may be closed and the proposer may publish to crates.io. This is controlled by those in the [crate publishers organization-level team](https://github.com/orgs/rust-rocksdb/teams/crate-publishers). +* Releases should have an associated tag pushed to this repo +* The changelog serves as a sort of logical staging area for releases +* If a breaking API change happens, and the changelog has not advanced to a new major version, we roll the changelog to a new major version and open an issue to release the previous patch (and post-1.0, minor) version. +* Before rolling to a new major version, it would be nice to release a non-breaking point release to let current users silently take advantage of any improvements + +#### Becoming a Maintainer + +* If you have a history of participation in this repo, agree to these rules, and wish to take on maintainership responsibilities, you may open an issue. If an owner agrees, they will add you to the maintainer group and the crate publishers team. From 4ee361d273ef458e6ecbfc8ced9013009a396eac Mon Sep 17 00:00:00 2001 From: Tyler Neely Date: Sat, 13 Oct 2018 10:02:39 +0200 Subject: [PATCH 2/3] Update MAINTAINERSHIP.md --- MAINTAINERSHIP.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERSHIP.md b/MAINTAINERSHIP.md index 5095a75..a691cae 100644 --- a/MAINTAINERSHIP.md +++ b/MAINTAINERSHIP.md @@ -32,7 +32,7 @@ If any maintainer thinks an issue is major, it is major. * To cut a release, an issue should be opened for it and reach the required approval based on the above `Categories of Work` section above * When progress is possible, the issue may be closed and the proposer may publish to crates.io. This is controlled by those in the [crate publishers organization-level team](https://github.com/orgs/rust-rocksdb/teams/crate-publishers). -* Releases should have an associated tag pushed to this repo +* Releases should have an associated tag pushed to this repo. I recommend doing this after the publish to crates.io succeeds to prevent any mishaps around pushing a tag for something that can't actually be published. * The changelog serves as a sort of logical staging area for releases * If a breaking API change happens, and the changelog has not advanced to a new major version, we roll the changelog to a new major version and open an issue to release the previous patch (and post-1.0, minor) version. * Before rolling to a new major version, it would be nice to release a non-breaking point release to let current users silently take advantage of any improvements From fad49c206cf43331e4704d9946f782c1e9d3131b Mon Sep 17 00:00:00 2001 From: Tyler Neely Date: Sat, 3 Nov 2018 18:19:19 +0100 Subject: [PATCH 3/3] Update MAINTAINERSHIP.md --- MAINTAINERSHIP.md | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERSHIP.md b/MAINTAINERSHIP.md index a691cae..af038c4 100644 --- a/MAINTAINERSHIP.md +++ b/MAINTAINERSHIP.md @@ -30,6 +30,7 @@ If any maintainer thinks an issue is major, it is major. #### Releasing, Publishing +* Releases adhere to [semver](https://semver.org/) * To cut a release, an issue should be opened for it and reach the required approval based on the above `Categories of Work` section above * When progress is possible, the issue may be closed and the proposer may publish to crates.io. This is controlled by those in the [crate publishers organization-level team](https://github.com/orgs/rust-rocksdb/teams/crate-publishers). * Releases should have an associated tag pushed to this repo. I recommend doing this after the publish to crates.io succeeds to prevent any mishaps around pushing a tag for something that can't actually be published.