Merge pull request #1004 from betatim/setup-monthly-releases

.github/workflows/release.yml

@@ -0,0 +1,34 @@
+name: Create a release on pypi.org
+
+on:
+  push:
+  pull_request:
+
+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 }}

.travis.yml

@@ -1,46 +0,0 @@
-dist: xenial
-os: linux
-language: python
-cache: pip
-services:
-- docker
-python:
-- 3.8
-install:
-# Make a wheel and install it to test to catch possible
-# issues with releases
-- pip install --upgrade setuptools pip
-- pip install -r dev-requirements.txt
-- python setup.py bdist_wheel
-- pip install dist/*.whl
-- pip freeze
-script:
-- |
-  # run autoformat
-  if [[ "$REPO_TYPE" == "lint" ]]; then
-    pre-commit run --all-files
-  fi
-after_success:
-- pip install codecov
-- pushd tests && codecov && popd
-
-after_failure:
-- |
-  # point to auto-lint-fix
-  echo "You can install pre-commit hooks to automatically run formatting"
-  echo "on each commit with:"
-  echo "    pre-commit install"
-  echo "or you can run by hand on staged files with"
-  echo "    pre-commit run"
-  echo "or after-the-fact on already committed files with"
-  echo "    pre-commit run --all-files"
-
-deploy:
-  provider: pypi
-  username: mybinderteam
-  distributions: sdist bdist_wheel
-  on:
-    tags: true
-    repo: jupyterhub/repo2docker
-  password:
-    secure: ZkJTcI6fVkh2yRB0UVwSPVvGtfade7sQDZ6BjQR5bHRZuBLFq4/nxmn88BIPc6uYEHB6hxxfr9RbyP7ZnyUVUoTiyRfDM8kQe0RvFUVxRj7brZZFMYt6OTMiPUgWvyDqYIdVx+D5qgFgLxnQtUiZ0iqvPgQ+9Jn5SxZuuovrARpaTavlmKo4Vw63Ks/3zV61YeehvELFxU2Ibjy5ujMo/R119KZ7G3Z1w0IyJyVZQ9WaG1VXLO1LjFifpCcjMawaTJ9TmD5BOdF4IAIlP2QlB9N+v2xxuEGy7Mc9FwAH6M8kNqmjhe/ayj83vEMmlkxhE66unqiFJkSXzH1Rh8ythOy9s9qiDgeZeW/rYYLrzVNl9aMHicidV4PKEzobwXS/u8c/wx0fsAMNPcHY+O/8+hFLwy4ZLHusNiyCjPv5sVOq7yM/EKCjkod71bzFOvnnCZ70S0pxrR1nwEKo3x8qaK7l9aw0raSgWyrp6VHzEI4zPfBvP+R2ZYCUqBBj7rrpEl2C02AMKEkTh7Xm5LpaAFCBBMUwTATg7hECmB232vO+C6CLED+ONmGost5jOgsGwIun6viM5eXhP1tCeC5XeAtYozo/9UUIc5yHZL/8YtnmfCxvSi7p6h4qgLDCviKTH3bJCsRjF1ktkTiWAT+wL/SywsRz5D9tjV4b70neM8I=

CONTRIBUTING.md

@@ -23,4 +23,4 @@ There are a few other pages to highlight:
     Its a good place to understand _why_ the team have made the decisions that they have along the way!
   * We absolutely encourage discussion around refactoring, updating or extending repo2docker, but please make sure that you've understood this page before opening an issue to discuss the change you'd like to propose.
 * [Common developer tasks and how-tos](https://repo2docker.readthedocs.io/en/latest/contributing/tasks.html)
-  * Some notes on running tests, buildpack dependencies, creating a release, updating the changelog and keeping the pip files up to date.
+  * Some notes on running tests, buildpack dependencies, creating a release, and keeping the pip files up to date.

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 use "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