diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml new file mode 100644 index 000000000..d8a5f30e7 --- /dev/null +++ b/.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 }} diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 9467a64c4..000000000 --- a/.travis.yml +++ /dev/null @@ -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= diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1a02fa1a5..f1a583d59 100644 --- a/CONTRIBUTING.md +++ b/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. diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index c7903e54d..5e0a0075c 100644 --- a/docs/source/contributing/contributing.md +++ b/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" ..` 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. diff --git a/docs/source/contributing/tasks.md b/docs/source/contributing/tasks.md index a1f6a34d0..780033c7f 100644 --- a/docs/source/contributing/tasks.md +++ b/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