Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Simplify Release Process #1061

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Simplify Release Process #1061

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4f19492
first pass refactor release process
asonnenschein Oct 2, 2024
9b3b298
finalize release changes and delete changelog
asonnenschein Oct 3, 2024
23c821d
add changes.txt back
asonnenschein Oct 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CHANGES.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -440,4 +440,4 @@ package is coming soon. The highlights are

0.0.1 (2015-07-17)
------------------
- Initial release
- Initial release
79 changes: 18 additions & 61 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,76 +2,33 @@

*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.pypi, release on pypi is triggered manually with the Github Action "Automatically Publish on TestPyPi". There is also an option to publish to test.pypi and pypi from your local machine.
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 `Autopublish to TestPyPI`. There is also an option to publish to test.pypi and PyPI from your local machine.

The first step in a release is determining if the release is a feature release or a maintenance release. A maintenance release is a backward compatible bug fix or documentation change, while a feature release adds functionality in a backward compatible manner.
## Versions and Stability

#### Release Naming Conventions
The SDK follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html) and therefore only major releases should break compatibility. Minor versions may include new functionality and patch versions address bugs or trivial changes (like documentation).

This project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html), which specifies a version number as MAJOR.MINOR.PATCH with a feature release mapped to a MINOR version and a maintenance release mapped to a PATCH.
If depending upon official packages from PyPI, a developer should feel comfortable specifying `planet == 2.*` unless depending on a specific feature introduced at a minor version, in which case `planet == 2.x.*` (where x is the minor version of the new feature) should suffice.

The following are the release naming conventions:
The default branch is always `main` and should be considered in-development but with tests and other build steps succeeding.

1. Current Dev Version is obtained from `planet/__version__.py`
* For maintenance release, the format is `{MAJOR.MINOR.PATCH}dev`
* For feature release, the format is `{MAJOR.MINOR}dev`
3. Release Version: Remove `dev` from Current Dev Version
4. Next Dev Version: Bumped version of Release Version with `dev` added to the end.
* For maintenance release, bump PATCH
* For feature release, bump MINOR, do not specify PATCH
5. Source branch:
* For maintenance release, source branch is `maint-{MAJOR.MINOR}`
* For feature release, source branch is the main branch, `main`

## Release Workflow

##### Maintenance Release Example:

**IF** Current Dev Version == `1.1.1dev` **THEN**
* Release Version: `1.1.1`
* Next Dev Version: `1.1.2dev`
* Source Branch: `maint-1.1`


##### Feature Release Example:

**IF** Current Dev Version == `1.2dev` **THEN**
* Release Version: `1.2`
* Next Dev Version: `1.3dev`
* Source Branch: `main`

1. Create a release branch off of `main` that bumps the SDK version number and updates the changelog:
* Bump SDK version number in `planet/__version__.py`
2. Create a PR for the release branch and merge into `main`
3. Create a new GitHub release:
* Set tag to release version
* Set target to `main`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also tag in git and push the tag
e.g.

  • git tag <release_version>
  • git push <release_version>
  • Create a new github release with the target as the tag

* Set title to tag release version
* Add short description of changes, adhering to [Keep a Changelog](https://keepachangelog.com/en/1.1.0/#how).
4. Verify the successful run of the Github Action `Autopublish to TestPyPI` and validate the test release on [test.pypi.org](https://test.pypi.org/project/planet/)
5. Run the Github Action `Publish on PyPI`
6. Verify the successful run of the Github Action `Publish on PyPI` and validate the release on [pypi.org](https://pypi.org/project/planet/)

## Release Workflow

The release on Github and PyPi performed from a release branch while the release branch PR is in progress. After the releases, the version in the PR is updated before it is merged. Thus, the version in `main` is not the same as the version of the release.

*NOTE: This section refers to version and branch names given in Release Naming Conventions section above.*

1. Starting from the Source Branch, create a release branch named `release-{Release Version}`
1. Make the following changes for the release:
* Update `CHANGES.txt`, adhering to [Keep a Changelog](https://keepachangelog.com/)
* Include added, changed, deprecated or removed features and bug fixes.
A list of merged PRs and their titles since the last release can be obtained with `git log $PREVIOUS_RELEASE_TAG..HEAD | awk '/Merge pull request/{print;getline;getline;print}'`.
* Sort according to importance
* Update `planet/__version__.py` to Release Version
1. Create a PR for the release branch (named after release branch, description is changelog entry, base is Source Branch), wait for CI to pass
1. Create a new github release:
* Set Tag to Release Version
* **!!!** Set Target to the release branch **!!!**
* Set Title to Tag Release Version
* Copy Description from the new entry in the changelog
* Select "This is a pre-release" if applicable
1. Verify the successful run of the Github Action "Autopublish to TestPyPi" and validate the test release on [test.pypi.org](https://test.pypi.org/project/planet/)
1. Run the Github Action "Publish on PyPi", **!!!** Set Branch to the release branch **!!!**
1. Verify the successful run of the Github Action "Publish on PyPi" and validate the release on [pypi.org](https://pypi.org/project/planet/)
1. Push a commit to the PR updating `planet/__version__.py` to Next Dev Version
1. Merge PR
1. Announce the release through the following avenues:
* *Planet Internal:* #python and #devrel slack channels
* Changelog
1. Maintenance release only: Merge release tag into `main`


### Local publishing
## Local publishing

Publishing to testpypi and pypi can also be performed locally with:

Expand Down
Loading