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: CONTRIBUTING.md
+25-4
Original file line number
Diff line number
Diff line change
@@ -5,19 +5,40 @@ document explains how to contribute successfully.
5
5
6
6
## Workflows
7
7
8
-
### Development
8
+
### Branches
9
9
10
-
#### Development Branch
10
+
#### Mainline Branches
11
11
12
-
The default branch is always `main` and should be always considered in-development. Feature enhancements, bug fixes, and other maintenance should be performed in a development branch, starting with the appropriate base branch and merged back into that branch:
12
+
The default branch is always `main`, and will correspond to the current stable major release version.
13
+
This branch should be considered in-development but with tests and other build steps kept in a passing
14
+
and stable state.
15
+
16
+
Branches for future major releases will be named `main-X.0-dev` where `X.0` is the next major
17
+
release version. These branches will be kept current with the current stable major release
18
+
insofar as is practical within the scope of changes targeted to the next major release. Per semantic
19
+
versioning, major releases do not guarantee backwards compatibility. Stability is not guaranteed
20
+
during the development cycle.
21
+
22
+
During the development cycle of a new major release, `RELEASE-PLANNING-X.0.md` should be maintained
23
+
with a brief summary of the major and breaking changes underpinning the reason for the upcoming
24
+
major release version. Upon release, this content is expected to be folded into package documentation
25
+
as appropriate, and this file should be removed.
26
+
27
+
When a new major release is ready, the development mainline branch will be renamed to `main`, and the
28
+
old mainline branch will be renamed to `maint-X.0` and will be used as the base for maintenance releases.
29
+
30
+
#### Development Branches
31
+
32
+
Feature enhancements, bug fixes, and other maintenance should be performed in a development
33
+
branch, starting with the appropriate base branch and merged back into that branch:
13
34
14
35
```console
15
36
git checkout main
16
37
git pull
17
38
git checkout -b new-branch-name
18
39
```
19
40
20
-
#### Branch Naming
41
+
#### Development Branch Naming
21
42
22
43
Branch names should describe the work performed within the branch, and include a ticket number if applicable. For example, a branch that corrects typos in documentation and is not ticketed could be named `fix-documentation-typos`, and a branch that adds a new feature and is ticketed could be named `new-feature-123` (where 'new-feature' is the name of the feature and '-123' is the ticket number).
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).
27
-
28
-
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.
29
-
30
-
The default branch is always `main` and should be considered in-development but with tests and other build steps succeeding.
26
+
The SDK follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html) and therefore only major releases
27
+
should break compatibility. Minor versions may include new functionality and
28
+
patch versions address bugs or trivial changes (like documentation).
29
+
30
+
Packages will be released to [PyPi / Planet](https://pypi.org/project/planet/)
31
+
with semantic version identifiers that comply with [PEP 440](https://peps.python.org/pep-0440/).
32
+
33
+
The Semantic Versioning stability scheme only applies to APIs that
34
+
are considered part of the public API. This includes library APIs exported
0 commit comments