diff --git a/CHANGELOG.md b/CHANGELOG.md
index 3238f55..add5923 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,7 +1,9 @@
-## v0.7.0 (2019-10-21)
+## v1.0.0b1 (2019-12-26)
 - Python 3.7+ required (asyncio support)
 - TLS/SSL support using asyncio
 - Windows support
+- General cleanup
+- May be incompatible with code written for pycapnp 0.6.4 and lower
 
 ## v0.6.4 (2019-01-31)
 - Fix bugs in `read_multiple_bytes` (thanks to @tsh56)
diff --git a/DEPLOY.md b/DEPLOY.md
deleted file mode 100644
index 69eae40..0000000
--- a/DEPLOY.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Deployment instructions for PyPi
-
-This file is meant for maintainers of pycapnp, and documents the process for uploading to PyPI.
-
-## Pre-requisites
-
-```
-pip install pypandoc cython
-```
-
-## Run tests
-
-I typically sanity check by running the tests once again locally, but as long as Travis is green, you're probably fine.
-
-## Add a commit that bumps the version
-
-Bump the version in setup.py, and add descriptions of all the changes to CHANGELOG.md (see 19e1b189caa786c7f572e679d6bb94aadfbdb5e0 for an example commit).
-
-## Run the build and upload
-
-Run the following command to clean up old artifacts, run the build, and then upload the result to PyPI
-
-```
-rm -rf bundled/ capnp/version.py capnp/lib/capnp.{h,cpp} build; python setup.py build && python setup.py sdist upload -r PyPI
-```
-
-## Test the PyPI release
-
-I manually test the PyPI release after it's been uploaded. I have a few virtualenvs that I manually run the following command in (run this from the pycapnp directory since it runs the tests at the end):
-```
-yes | pip uninstall pycapnp; pip install pycapnp && py.test test
-```
-
-I usually test the following configurations:
-- Python 2.7 with and without cython installed
-- Python 3.6 with and without cython installed
-
-This step could probably benefit greatly from some automation. Perhaps even Travis could handle it, but I'm not sure how best to trigger Travis from a PyPI release.
-
-## Tag the github release
-
-Tag the release on the develop branch (not the master branch). Sadly, I've stopped using git-flow, and at this point it might be worth moving back to using just master, but that would take some amount of work and I worry that it would break open PRs. Definitely worth considering if development picks back up.
-
-Version numbers roughly follow semver, although I try to loosely follow upstream Cap'n Proto C++ versions as well. So when pycapnp officially starts using v0.7.0 of the C++ library, pycapnp's version should be bumped to v0.7.0 as well.
diff --git a/setup.py b/setup.py
index c1e8cb0..10aa511 100644
--- a/setup.py
+++ b/setup.py
@@ -20,10 +20,11 @@ from buildutils import test_build, fetch_libcapnp, build_libcapnp, info
 
 _this_dir = os.path.dirname(__file__)
 
-MAJOR = 0
-MINOR = 7
+MAJOR = 1
+MINOR = 0
 MICRO = 0
-VERSION = '%d.%d.%d' % (MAJOR, MINOR, MICRO)
+TAG = 'b1'
+VERSION = '%d.%d.%d%s' % (MAJOR, MINOR, MICRO, TAG)
 
 
 # Write version info