Add workflow to push a release to pypi

This adds a new GH Action workflow that will build and upload a new
package to pypi.org. The release instructions are updated to use
calendar versioning. Outdated instructions related to the change log
have been removed.

Author: betatim

.github/workflows/release.yml

@@ -0,0 +1,32 @@
+name: Create a release on pypi.org
+
+on: push
+
+jobs:
+  build-n-publish:
+    runs-on: ubuntu-18.04
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: "Setup Python 3.8"
+        uses: actions/setup-python@v2
+        with:
+          python-version: "3.8"
+
+      - name: "Install dependencies"
+        run: |
+          pip install --upgrade setuptools pip
+          pip install --upgrade -r dev-requirements.txt
+          pip freeze
+
+      - name: "Build distribution archives"
+        run: |
+          python setup.py sdist bdist_wheel
+
+      # This step is only run when a new tag is pushed
+      # all previous steps always run in order to exercise them
+      - name: Publish distribution to PyPI
+        if: startsWith(github.ref, 'refs/tags')
+        uses: pypa/gh-action-pypi-publish@master
+        with:
+          password: ${{ secrets.PYPI_API_TOKEN }}

docs/source/contributing/contributing.md

@@ -61,10 +61,11 @@ This outlines the process for getting changes to the repo2docker project merged.
 3. Make edits in [your fork](https://help.github.com/en/articles/fork-a-repo) of the [repo2docker repository](https://github.com/jupyterhub/repo2docker).
 4. Make a [pull request](https://help.github.com/en/articles/about-pull-requests).
 Read the [next section](#guidelines-to-getting-a-pull-request-merged) for guidelines for both reviewers and contributors on merging a PR.
-5. Edit [the changelog](./../../changelog) by appending your feature / bug fix to the development version.
 6. Wait for a community member to merge your changes.
   Remember that **someone else must merge your pull request**.
   That goes for new contributors and long term maintainers alike.
+  Because `master` is continuously deployed to mybinder.org it is essential
+  that `master` is always in a deployable state.
 7. (optional) Deploy a new version of repo2docker to mybinder.org by [following these steps](http://mybinder-sre.readthedocs.io/en/latest/deployment/how.html)
 
 ## Guidelines to getting a Pull Request merged
@@ -84,7 +85,6 @@ These are not hard rules to be enforced by 🚓 but they are suggestions written
   This makes it easier to find all changes since the last deployment `git log --merges --pretty=format:"%h %<(10,trunc)%an %<(15)%ar %s" <deployed-revision>..` and your PR easier to review.
 * **Make it clear when your PR is ready for review.**
   Prefix the title of your pull request (PR) with `[MRG]` if the contribution is complete and should be subjected to a detailed review.
-* **Enter your changes into the [changelog](./../../changelog)** in `docs/source/changelog.rst`.
 * **Use commit messages to describe _why_ you are proposing the changes you are proposing.**
 * **Try to not rush changes** (the definition of rush depends on how big your changes are).
   Remember that everyone in the repo2docker team is a volunteer and we can not (nor would we want to) control their time or interests.

docs/source/contributing/tasks.md

@@ -113,41 +113,35 @@ added and why. If you fix a bug or add new functionality consider adding a new
 test to prevent the bug from coming back/the feature breaking in the future.
 
 
-
 ## Creating a Release
 
-We try to make a release of repo2docker every few months if possible.
-
-We follow [semantic versioning](https://semver.org/).
+We make a release of whatever is on `master` every month. We uses "calendar versioning".
+Monthly releases give users a predictable pattern for when releases are going to
+happen and prevents locking up improvements for fixes for long periods of time.
 
 A new release will automatically be created when a new git tag is created
-and pushed to the repository (using
-[Travis CI](https://github.com/jupyterhub/repo2docker/blob/master/.travis.yml#L52)).
+and pushed to the repository.
 
 To create a new release, follow these steps:
 
-### Confirm that the changelog is ready
-
-[The changelog](https://github.com/jupyterhub/repo2docker/blob/master/docs/source/changelog.rst)
-should reflect all significant enhancements and fixes to repo2docker and
-its documentation. In addition, ensure that the correct version is displayed
-at the top, and create a new `dev` section if needed.
-
 ### Create a new tag and push it
 
 First, tag a new release locally:
 
 ```bash
-V=0.7.0; git tag -am "release $V" $V
+V=YYYY.MM.0; git tag -am "release $V" $V
 ```
 
+> If you need to make a second (or third) release in a month increment the
+> trailing 0 of the version to 1 (or 2).
+
 Then push this change up to the master repository
 
 ```
 git push origin --tags
 ```
 
-Travis should automatically run the tests and, if they pass, create a
+GitHub Actions should create a
 new release on the [repo2docker PyPI](https://pypi.org/project/jupyter-repo2docker/).
 Once this has completed, make sure that the new version has been updated.
 
@@ -159,51 +153,10 @@ release on the [GitHub repository releases page](https://github.com/jupyterhub/r
 * Click "Draft a new release"
 * Choose a tag version using the same tag you just created above
 * The release name is simply the tag version
-* The description is [a link to the Changelog](https://github.com/jupyterhub/repo2docker/blob/master/docs/source/changelog.rst),
-  ideally with an anchor to the latest release.
 * Finally, click "Publish release"
 
 That's it!
 
-## Update the change log
-
-To add your change to the change log, find the relevant Feature/Bug
-fix/API change section for the next release near the top of the file;
-then add one or two sentences as a new bullet point about your
-changes. Include the pull request or issue number between square
-brackets at the end.
-
-Some details:
-
-- versioning follows the x.y.z, major.minor.bugfix numbering
-
-- bug fixes go into the next bugfix release. If there isn't any, you
-  can create a new section (see point below). Don't worry if you're
-  not sure about that, and think it should go into a next major or
-  minor release: an admin will let you know, or move the change later
-  to the appropriate section
-
-- API changes should preferably go into the next major release, unless
-  they are backward compatible (for example, a deprecated function
-  keyword): then they can go into the next minor release. For release
-  with major release 0, non-backward compatible breaking changes are
-  also fine for the next minor release.
-
-- new features should go into the next minor release.
-
-- if there is no section for the appropriate release, you can add one:
-
-  follow the versioning scheme, by simply increasing the relevant
-  number for one of the major /minor/bugfix numbers, appropriate for
-  your change (see the above bullet points); add the release
-  section. Then add three subsections: new features, api changes, and
-  bug fixes. Leave out the sections that are not appropriate for the
-  newlye added release section.
-
-Release candidate versions in the change log are only temporary, and
-should be superseded by either a next release candidate, or the final
-release for that version (bugfix version 0).
-
 
 ## Keeping the Pipfile and requirements files up to date