From b1b6a4cdc312d919fa8c1fd274a2f748397ecff4 Mon Sep 17 00:00:00 2001 From: Jimmy Jia Date: Thu, 25 Jun 2015 14:21:42 -0400 Subject: [PATCH] [changed] Add two-release deprecation policy Fixes #863 --- CONTRIBUTING.md | 10 ++++++++++ MAINTAINING.md | 14 +++++++------- README.md | 2 +- 3 files changed, 18 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e063b3342a..0f939d1f8d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -82,6 +82,16 @@ Also Bootstrap mentions http://getbootstrap.com/getting-started/#examples as examples of things you can do, but they are not part of the core library, therefore this project is the wrong place to implement them. +## Breaking changes + +Breaking changes should be accompanied with deprecations of removed +functionality. Prior to the 1.0.0 release, we aim to follow React's example of +taking two Minor releases to break old functionality. As such, changes that +intend to remove or change public APIs should be be submitted against the +`vX-rc` branch, and should be accompanied with deprecation warnings on the old +APIs. The deprecated APIs themselves should not be removed until the Minor +release after that. + ## Collaborators diff --git a/MAINTAINING.md b/MAINTAINING.md index e6c5f29b14..402e8379ae 100644 --- a/MAINTAINING.md +++ b/MAINTAINING.md @@ -95,13 +95,13 @@ then be re-applied and released with the proper version bump. ### Release Candidates In an effort to reduce the frequency with which we introduce breaking changes we -should do our best to first push deprecation warnings in a Minor or Patch -release. Also, Pull Requests with breaking changes should be submitted against -the `vX-rc` branch, where X is the next Major version. Which we will in turn -release as an `alpha` release of the next Major version. When we are ready to -release the next Major version bump we will merge the `vX-rc` branch into the -`master` branch and cut a `beta` release. Once bugs have been addressed with -the `beta` release then we will release the Major version bump. +should do our best to first push deprecation warnings in a Minor release. Also, +Pull Requests with breaking changes should be submitted against the `vX-rc` +branch, where X is the next Major version. Which we will in turn release as an +`alpha` release of the next Major version. When we are ready to release the next +Major version bump we will merge the `vX-rc` branch into the `master` branch and +cut a `beta` release. Once bugs have been addressed with the `beta` release +then we will release the Major version bump. ### Live releasing the documentation diff --git a/README.md b/README.md index f05ea61500..3b8833288e 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ [![devDependency Status][dev-deps-badge]][dev-deps] [![peerDependency Status][peer-deps-badge]][peer-deps] -__Under active development - APIs will change.__ Check out the [1.0.0 Roadmap](https://github.com/react-bootstrap/react-bootstrap/wiki#100-roadmap) and [Contributing Guidelines][contributing] to see where you can help out. Prior to the 1.0.0 release, breaking changes should result in a Minor version bump. +__Under active development - APIs will change.__ Check out the [1.0.0 Roadmap](https://github.com/react-bootstrap/react-bootstrap/wiki#100-roadmap) and [Contributing Guidelines][contributing] to see where you can help out. Prior to the 1.0.0 release, deprecations or breaking changes should result in a Minor version bump. ## Docs