You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: RELEASE.md
+38-16Lines changed: 38 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,37 +4,56 @@
4
4
5
5
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.
6
6
7
+
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.
8
+
7
9
#### Release Naming Conventions
8
10
11
+
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.
12
+
9
13
The following are the release naming conventions:
10
14
11
15
1. Current Dev Version is obtained from `planet/__version__.py`
16
+
* For maintenance release, the format is `{MAJOR.MINOR.PATCH}dev`
17
+
* For feature release, the format is `{MAJOR.MINOR}dev`
12
18
3. Release Version: Remove `dev` from Current Dev Version
13
-
4. Next Dev Version: Bumped version of last release with `dev` added to the end.
14
-
* Bumped version number is determined by [Semantic Versioning](https://semver.org/spec/v2.0.0.html)
19
+
4. Next Dev Version: Bumped version of Release Version with `dev` added to the end.
20
+
* For maintenance release, bump PATCH
21
+
* For feature release, bump MINOR, do not specify PATCH
22
+
5. Source branch:
23
+
* For maintenance release, source branch is `maint-{MAJOR.MINOR}`
24
+
* For feature release, source branch is the main branch, `main`
25
+
26
+
27
+
##### Maintenance Release Example:
28
+
29
+
**IF** Current Dev Version == `1.1.1dev`**THEN**
30
+
* Release Version: `1.1.1`
31
+
* Next Dev Version: `1.1.2dev`
32
+
* Source Branch: `maint-1.1`
15
33
16
34
17
-
##### Example:
35
+
##### Feature Release Example:
36
+
37
+
**IF** Current Dev Version == `1.2dev`**THEN**
38
+
* Release Version: `1.2`
39
+
* Next Dev Version: `1.3dev`
40
+
* Source Branch: `main`
18
41
19
-
**IF** Current Dev Version == `1.0.0dev`**THEN**
20
-
* Release Version: `1.0.0`
21
-
* Next Dev Version: `1.0.1dev`
22
42
23
43
## Release Workflow
24
44
25
45
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.
26
46
27
-
*NOTE: This section refers to version names given in Release Naming Conventions section above.*
47
+
*NOTE: This section refers to version and branch names given in Release Naming Conventions section above.*
28
48
29
-
1.Create a release branch named `release-{Release Version}`
30
-
1. Make the following changes for the release
31
-
* Update `CHANGES.txt` (**PROPOSAL**: change this to `docs/CHANGELOG.md`)
49
+
1.Starting from the Source Branch, create a release branch named `release-{Release Version}`
50
+
1. Make the following changes for the release:
51
+
* Update `CHANGES.txt`, adhering to [Keep a Changelog](https://keepachangelog.com/)
32
52
* Include added, changed, depricated or removed features and bug fixes.
33
-
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}`.
53
+
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}'`.
34
54
* Sort according to importance
35
-
***PROPOSAL**: Adhere to [Keep a Changelog](https://keepachangelog.com/)
36
55
* Update `planet/__version__.py` to Release Version
37
-
1. Create a PR for the release branch (named after release branch, description is changelog entry), wait for CI to pass
56
+
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
38
57
1. Create a new github release:
39
58
* Set Tag to Release Version
40
59
***!!!** Set Target to the release branch **!!!**
@@ -47,9 +66,10 @@ The release on Github and PyPi performed from a release branch while the release
47
66
1. Push a commit to the PR updating `planet/__version__.py` to Next Dev Version
48
67
1. Merge PR
49
68
1. Announce the release through the following avenues:
50
-
**Planet Internal:* #python slack channel
69
+
**Planet Internal:* #python and #devrel slack channels
51
70
* Changelog
52
-
* Twitter
71
+
1. Maintenace release only: Merge release tag into `main`
72
+
53
73
54
74
### Local publishing
55
75
@@ -62,7 +82,9 @@ then
62
82
```console
63
83
$ nox -s publish-pypi
64
84
```
65
-
this approach requires specifying the pypi/testpypi api token as the password at the prompt.
85
+
86
+
This approach requires specifying the pypi/testpypi api token as the password at the prompt.
0 commit comments