Skip to content

Commit

Permalink
[changed] Add two-release deprecation policy
Browse files Browse the repository at this point in the history
  • Loading branch information
Jimmy Jia committed Jun 25, 2015
1 parent 2a0b073 commit b1b6a4c
Show file tree
Hide file tree
Showing 3 changed files with 18 additions and 8 deletions.
10 changes: 10 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
14 changes: 7 additions & 7 deletions MAINTAINING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down

0 comments on commit b1b6a4c

Please sign in to comment.