Skip to content

Commit

Permalink
chore: tag 2.3.0 release
Browse files Browse the repository at this point in the history
  • Loading branch information
bbangert committed Jun 1, 2017
1 parent 3a657b9 commit f07e2e7
Show file tree
Hide file tree
Showing 8 changed files with 811 additions and 782 deletions.
614 changes: 614 additions & 0 deletions CHANGES.md

Large diffs are not rendered by default.

659 changes: 0 additions & 659 deletions CHANGES.rst

This file was deleted.

166 changes: 166 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,166 @@
# Contribution Guidelines

We gladly accept outside contributions. We use our
[Github issue tracker](https://github.com/python-zk/kazoo/issues)
for both discussions and talking about new features or bugs. You can
also fork the project and sent us a pull request. If you have a more
general topic to discuss, the
[[email protected]](https://zookeeper.apache.org/lists.html)
mailing list is a good place to do so. You can sometimes find us on
IRC in the
[#zookeeper channel on freenode](https://zookeeper.apache.org/irc.html).

[See the README](/README.rst) for contact information.

## Development

If you want to work on the code and sent us a
[pull request](https://help.github.com/articles/using-pull-requests),
first fork the repository on github to your own account. Then clone
your new repository and run the build scripts:

```
git clone [email protected]:<username>/kazoo.git
cd kazoo
make
```

You need to have some supported version of Python installed and have
it available as `python` in your shell. To run Zookeeper you also
need a Java runtime (JRE or JDK) version 6 or 7. To run tests, you
need to have the tox, Python testing tool, to be installed in your shell.

You can run all the tests by calling:

```
make test
```

Or to run individual tests:

```
export ZOOKEEPER_PATH=/<path to current folder>/bin/zookeeper/
bin/nosetests -s -d kazoo.tests.test_client:TestClient.test_create
```

The nose test runner allows you to filter by test module, class or
individual test method.

If you made changes to the documentation, you can build it locally:

```
make html
```

And then open `./docs/_build/html/index.html` in a web browser to
verify the correct rendering.


## Bug Reports

You can file issues here on GitHub. Please try to include as much information as
you can and under what conditions you saw the issue.

## Adding Recipes

New recipes are welcome, however they should include the status/maintainer
RST information so its clear who is maintaining the recipe. This does mean
that if you submit a recipe for inclusion with Kazoo, you should be ready
to support/maintain it, and address bugs that may be found.

Ideally a recipe should have at least two maintainers.

## Sending Pull Requests

Patches should be submitted as pull requests (PR).

Before submitting a PR:
- Your code must run and pass all the automated tests before you submit your PR
for review. "Work in progress" pull requests are allowed to be submitted, but
should be clearly labeled as such and should not be merged until all tests
pass and the code has been reviewed.
- Your patch should include new tests that cover your changes. It is your and
your reviewer's responsibility to ensure your patch includes adequate tests.

When submitting a PR:
- You agree to license your code under the project's open source license
([APL 2.0](/LICENSE)).
- Base your branch off the current `master`.
- Add both your code and new tests if relevant.
- Sign your git commit.
- Run the test suite to make sure your code passes linting and tests.
- Ensure your changes do not reduce code coverage of the test suite.
- Please do not include merge commits in pull requests; include only commits
with the new relevant code.


## Code Review

This project is production Mozilla code and subject to our [engineering practices and quality standards](https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities). Every patch must be peer reviewed.

## Git Commit Guidelines

We loosely follow the [Angular commit guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#type)
of `<type>(scope): <subject>` where `type` must be one of:

* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
semi-colons, etc)
* **refactor**: A code change that neither fixes a bug or adds a feature
* **perf**: A code change that improves performance
* **test**: Adding missing tests
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
generation

Scope may be left off if none of these components are applicable:

* **core**: Core client/connection handling
* **recipe**: Changes/Fixes/Additions to recipes

### Subject

The subject contains succinct description of the change:

* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end

### Body

In order to maintain a reference to the context of the commit, add
`closes #<issue_number>` if it closes a related issue or `issue #<issue_number>`
if it's a partial fix.

You can also write a detailed description of the commit: Just as in the
**subject**, use the imperative, present tense: "change" not "changed" nor
"changes" It should include the motivation for the change and contrast this with
previous behavior.

### Footer

The footer should contain any information about **Breaking Changes** and is also
the place to reference GitHub issues that this commit **Closes**.

### Example

A properly formatted commit message should look like:

```
feat(core): add tasty cookies to the client handler
Properly formatted commit messages provide understandable history and
documentation. This patch will provide a delicious cookie when all tests have
passed and the commit message is properly formatted.
BREAKING CHANGE: This patch requires developer to lower expectations about
what "delicious" and "cookie" may mean. Some sadness may result.
Closes #3.14, #9.75
```

# Legal

Currently we don't have any legal contributor agreement, so code
ownership stays with the original authors.
81 changes: 0 additions & 81 deletions CONTRIBUTING.rst

This file was deleted.

28 changes: 28 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
Kazoo
=====

![Travis Build](https://travis-ci.org/python-zk/kazoo.svg?branch=master)

![Latest Version](https://img.shields.io/pypi/v/kazoo.svg)

![Downloads](https://img.shields.io/pypi/dm/kazoo.svg)

`kazoo` implements a higher level API to [Apache
Zookeeper](http://zookeeper.apache.org/) for Python clients.

See [the full docs](http://kazoo.rtfd.org/) for more information.

License
-------

`kazoo` is offered under the Apache License 2.0.

Authors
-------

`kazoo` started under the [Nimbus
Project](http://www.nimbusproject.org/) and through collaboration with
the open-source community has been merged with code from
[Mozilla](http://www.mozilla.org/) and the [Zope
Corporation](http://zope.com/). It has since gathered an active
community of over fifty contributors.
39 changes: 0 additions & 39 deletions README.rst

This file was deleted.

2 changes: 1 addition & 1 deletion kazoo/version.py
Original file line number Diff line number Diff line change
@@ -1 +1 @@
__version__ = '2.2.1'
__version__ = '2.3.0'
4 changes: 2 additions & 2 deletions setup.py
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,9 @@
from setuptools import setup, find_packages

here = os.path.abspath(os.path.dirname(__file__))
with open(os.path.join(here, 'README.rst')) as f:
with open(os.path.join(here, 'README.md')) as f:
README = f.read()
with open(os.path.join(here, 'CHANGES.rst')) as f:
with open(os.path.join(here, 'CHANGES.md')) as f:
CHANGES = f.read()
version = ''
with open(os.path.join(here, 'kazoo', 'version.py')) as f:
Expand Down

0 comments on commit f07e2e7

Please sign in to comment.