From f572d3159c59d1c0fcec855e38e67aada1747fe3 Mon Sep 17 00:00:00 2001 From: Jennifer Reiber Kyle Date: Fri, 14 Oct 2022 12:07:27 -0700 Subject: [PATCH 1/5] move release process to its own doc --- CONTRIBUTING.md | 38 +------------------------------------- RELEASE.md | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 42 insertions(+), 37 deletions(-) create mode 100644 RELEASE.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5668272b0..faebea676 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -39,44 +39,8 @@ To minimize the feedback loop, we have configured Nox so that it can be used to ### Releasing -*Planet maintainers only* +The release process is outlined in [RELEASE.md](RELEASE.md) -Releasing is a two-step process: (1) releasing on Github and test.pypi and (2) releasing to pypi. Releasing on Github will automatically trigger a release on test.pypi via a Github Action. Following manual confirmation of a successful and satisfactory release on test.py, release on pypi is triggered manually with the Github Action "Automatically Publish on TestPyPi". - -###### Step 1: Release on Github - -1. Create a PR with the following: - * Update `CHANGES.txt` (**PROPOSAL**: change this to `docs/CHANGELOG.md`) - * Include added, changed, depricated or removed features and bug fixes. - A list of merged PRs and their titles since the last release can be obtained with `git log ..HEAD | awk '/Merge pull request/{print;getline;getline;print}` - * Sort according to importance - * **PROPOSAL**: Adhere to [Keep a Changelog](https://keepachangelog.com/) - * Bump version in `planet/__version__.py` - * **PROPOSAL**: Version number is determined by [Semantic Versioning](https://semver.org/spec/v2.0.0.html) -1. Merge the PR -1. Create a new github release: - * Set Tag to the version number specified in `planet/__version__.py` - * Copy Description from the new entry in `docs/CHANGELOG.md` - * Select "This is a pre-release" if applicable - * Select "Create a discussion for this release" - -###### Step 2: Release on pypi - -1. Verify the test release on [test.pypi.org](https://test.pypi.org/project/planet/) -1. Run the Github Action "Publish on PyPi" - -###### Local publishing - -Publishing to testpypi and pypi can also be performed locally with: - -```console - $ nox -s build publish-testpypi -``` -then -```console - $ nox -s publish-pypi -``` -this approach requires specifying the pypi/testpypi api token as the password at the prompt. ## Development Tools diff --git a/RELEASE.md b/RELEASE.md new file mode 100644 index 000000000..98e502573 --- /dev/null +++ b/RELEASE.md @@ -0,0 +1,41 @@ +# Release Process + +*Planet maintainers only* + +Releasing is a two-step process: (1) releasing on Github and test.pypi and (2) releasing to pypi. Releasing on Github will automatically trigger a release on test.pypi via a Github Action. Following manual confirmation of a successful and satisfactory release on test.py, release on pypi is triggered manually with the Github Action "Automatically Publish on TestPyPi". + +###### Step 1: Release on Github + +1. Create a PR with the following: + * Update `CHANGES.txt` (**PROPOSAL**: change this to `docs/CHANGELOG.md`) + * Include added, changed, depricated or removed features and bug fixes. + A list of merged PRs and their titles since the last release can be obtained with `git log ..HEAD | awk '/Merge pull request/{print;getline;getline;print}` + * Sort according to importance + * **PROPOSAL**: Adhere to [Keep a Changelog](https://keepachangelog.com/) + * Bump version in `planet/__version__.py` + * **PROPOSAL**: Version number is determined by [Semantic Versioning](https://semver.org/spec/v2.0.0.html) +1. Merge the PR +1. Create a new github release: + * Set Tag to the version number specified in `planet/__version__.py` + * Copy Description from the new entry in `docs/CHANGELOG.md` + * Select "This is a pre-release" if applicable + * Select "Create a discussion for this release" + +###### Step 2: Release on pypi + +1. Verify the test release on [test.pypi.org](https://test.pypi.org/project/planet/) +1. Run the Github Action "Publish on PyPi" + +###### Local publishing + +Publishing to testpypi and pypi can also be performed locally with: + +```console + $ nox -s build publish-testpypi +``` +then +```console + $ nox -s publish-pypi +``` +this approach requires specifying the pypi/testpypi api token as the password at the prompt. + From c44009f3370cd9ff3757ca220dceca908ab67fe7 Mon Sep 17 00:00:00 2001 From: Jennifer Reiber Kyle Date: Fri, 14 Oct 2022 12:18:02 -0700 Subject: [PATCH 2/5] add development branch info, add req for description for PR --- CONTRIBUTING.md | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index faebea676..1f9c15563 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,11 +15,32 @@ In the issue, provide the following: 1. Installed dependencies / versions 1. Error traceback +### Development + +#### Development Branch + +Most work should start with the latest instance of the `main` branch and be performed in a development branch: + +```console +git checkout main +git pull +git checkout -b new-branch-name +``` + +#### Branch Naming + +Please use the following naming convention for development branchs: + +`{up to 3-word summary of topic, separated by a dash)-{ticket number}` + +For example: `release-contributing-691` for [ticket 691](https://github.com/planetlabs/planet-client-python/issues/691). + ### Pull Requests Pull Request (PR) Requirements: 1. Must have a descriptive title. This populates the release changelog. +1. Must provide a summary of changes and examples of usage input / output in the case of user-interface changes. 1. Must include updates to relative documentation in docstrings and `docs` folder. See [Documentation](#documentation) section for information on docstring formatting and building. 1. Must pass all Continuous Integration (CI) checks. See below for more information on CI checks. 1. Must have at least one approval by a planet maintainer. @@ -39,9 +60,7 @@ To minimize the feedback loop, we have configured Nox so that it can be used to ### Releasing -The release process is outlined in [RELEASE.md](RELEASE.md) - - +The release process is outlined in [RELEASE.md](RELEASE.md). ## Development Tools From 0b56d8bcef1ba4f590c63a2796e5723e478aad59 Mon Sep 17 00:00:00 2001 From: Jennifer Reiber Kyle Date: Fri, 14 Oct 2022 12:55:42 -0700 Subject: [PATCH 3/5] add release naming conventions section and move to using dev in current development branch --- RELEASE.md | 35 ++++++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 7 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 98e502573..e132f9c1c 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -1,25 +1,47 @@ -# Release Process +# Version Release *Planet maintainers only* Releasing is a two-step process: (1) releasing on Github and test.pypi and (2) releasing to pypi. Releasing on Github will automatically trigger a release on test.pypi via a Github Action. Following manual confirmation of a successful and satisfactory release on test.py, release on pypi is triggered manually with the Github Action "Automatically Publish on TestPyPi". -###### Step 1: Release on Github +#### Release Naming Conventions -1. Create a PR with the following: +The following are the release naming conventions: + +1. Current dev version: Bumped version of last release with `dev` added to the end + * **PROPOSAL**: Version number is determined by [Semantic Versioning](https://semver.org/spec/v2.0.0.html) +1. Release version: Remove `dev` from current dev version + +Example +1. Last release version: `1.0.0` +1. Current dev version: `1.0.1dev` +1. Release version: `1.0.1` +1. Next dev version: `1.0.2dev` + +## Release Workflow + +#### Step 1: Release on Github + + + +1. Create a release branch +1. Make the following changes for the release: * Update `CHANGES.txt` (**PROPOSAL**: change this to `docs/CHANGELOG.md`) * Include added, changed, depricated or removed features and bug fixes. A list of merged PRs and their titles since the last release can be obtained with `git log ..HEAD | awk '/Merge pull request/{print;getline;getline;print}` * Sort according to importance * **PROPOSAL**: Adhere to [Keep a Changelog](https://keepachangelog.com/) - * Bump version in `planet/__version__.py` - * **PROPOSAL**: Version number is determined by [Semantic Versioning](https://semver.org/spec/v2.0.0.html) -1. Merge the PR + * Remove `dev` from version in `planet/__version__.py` +1. Create a PR for the release branch, wait for CI to pass 1. Create a new github release: * Set Tag to the version number specified in `planet/__version__.py` * Copy Description from the new entry in `docs/CHANGELOG.md` * Select "This is a pre-release" if applicable * Select "Create a discussion for this release" +1. Make the following post-release changes: + * Bump version number and append `dev` in `planet/__version__.py` + +1. Merge PR for release branch ###### Step 2: Release on pypi @@ -38,4 +60,3 @@ then $ nox -s publish-pypi ``` this approach requires specifying the pypi/testpypi api token as the password at the prompt. - From c2190955cb84bbc0d9a0696123a924ddd2475b5c Mon Sep 17 00:00:00 2001 From: Jennifer Reiber Kyle Date: Fri, 14 Oct 2022 12:59:42 -0700 Subject: [PATCH 4/5] capture unsaved changes to RELEASE.md --- RELEASE.md | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index e132f9c1c..292f7ea0b 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -12,35 +12,33 @@ The following are the release naming conventions: * **PROPOSAL**: Version number is determined by [Semantic Versioning](https://semver.org/spec/v2.0.0.html) 1. Release version: Remove `dev` from current dev version -Example -1. Last release version: `1.0.0` -1. Current dev version: `1.0.1dev` -1. Release version: `1.0.1` -1. Next dev version: `1.0.2dev` +Example: +* If + * Previous Release Version == `1.0.0` +* Then + * Current Dev Version: `1.0.1dev` + * Release Version: `1.0.1` + * Next Dev Version: `1.0.2dev` ## Release Workflow #### Step 1: Release on Github - - - -1. Create a release branch -1. Make the following changes for the release: +*NOTE: This section refers to version names given in Release Naming Conventions section above.* +1. Create a release branch named `release-{Release Version}` +1. Make the following changes for the release * Update `CHANGES.txt` (**PROPOSAL**: change this to `docs/CHANGELOG.md`) * Include added, changed, depricated or removed features and bug fixes. A list of merged PRs and their titles since the last release can be obtained with `git log ..HEAD | awk '/Merge pull request/{print;getline;getline;print}` * Sort according to importance * **PROPOSAL**: Adhere to [Keep a Changelog](https://keepachangelog.com/) - * Remove `dev` from version in `planet/__version__.py` -1. Create a PR for the release branch, wait for CI to pass + * Update `planet/__version__.py` to Release Version +1. Create a PR for the release branch (named after release branch), wait for CI to pass 1. Create a new github release: - * Set Tag to the version number specified in `planet/__version__.py` + * Set Tag to the version number specified in `planet/__version__.py`, aka Release Version * Copy Description from the new entry in `docs/CHANGELOG.md` * Select "This is a pre-release" if applicable * Select "Create a discussion for this release" -1. Make the following post-release changes: - * Bump version number and append `dev` in `planet/__version__.py` - +1. Update `planet/__version__.py` to Next Dev Version 1. Merge PR for release branch ###### Step 2: Release on pypi From bc9903e7229d978044e119baef42d84f9c733da6 Mon Sep 17 00:00:00 2001 From: Jennifer Reiber Kyle Date: Mon, 17 Oct 2022 14:48:21 -0700 Subject: [PATCH 5/5] test.py -> test.pypi Co-authored-by: Tim Schaub --- RELEASE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE.md b/RELEASE.md index 292f7ea0b..97748dd79 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -2,7 +2,7 @@ *Planet maintainers only* -Releasing is a two-step process: (1) releasing on Github and test.pypi and (2) releasing to pypi. Releasing on Github will automatically trigger a release on test.pypi via a Github Action. Following manual confirmation of a successful and satisfactory release on test.py, release on pypi is triggered manually with the Github Action "Automatically Publish on TestPyPi". +Releasing is a two-step process: (1) releasing on Github and test.pypi and (2) releasing to pypi. Releasing on Github will automatically trigger a release on test.pypi via a Github Action. Following manual confirmation of a successful and satisfactory release on test.pypi, release on pypi is triggered manually with the Github Action "Automatically Publish on TestPyPi". #### Release Naming Conventions