|
1 | 1 | # Policies |
2 | 2 |
|
3 | | -Parcels, as of v3.1.0, has adopted versioning and deprecation policies. |
4 | | - |
5 | 3 | ## Versioning |
6 | 4 |
|
7 | | -Parcels mostly follows [semantic versioning](https://semver.org/), where the version number (e.g., v2.1.0) is thought of as `MAJOR.MINOR.PATCH`. |
| 5 | +Parcels follows [Intended Effort Versioning (EffVer)](https://jacobtomlinson.dev/effver/), where the version number (e.g., v2.1.0) is thought of as `MACRO.MESO.MICRO`. |
8 | 6 |
|
9 | | -> MAJOR version for incompatible API changes<br> |
10 | | -> MINOR version for added functionality in a backward compatible manner<br> |
11 | | -> PATCH version for backward compatible bug fixes<br> |
| 7 | +> MACRO version - you will need to dedicate time to upgrading to this version<br> |
| 8 | +> MESO version - some small effort may be required for you to upgrade to this version<br> |
| 9 | +> MICRO version - no effort is intended for you to upgrade to this version<br> |
12 | 10 |
|
13 | | -Parcels doesn't implement strict backwards compatibility between minor versions. We may make small changes that deprecate elements of the codebase (e.g., an obscure parameter that is no longer needed). Such deprecations will follow our deprecation policy. |
| 11 | +When making backward incompatible changes, we will make sure these changes and instructions to upgrade are communicated to the user via change logs or migration guides, and (where applicable) informative error messaging. |
14 | 12 |
|
15 | 13 | Note when conducting research we highly recommend documenting which version of Parcels (and other packages) you are using. This can be as easy as doing `conda env export > environment.yml` alongside your project code. The Parcels version used to generate an output file is also stored as metadata entry in the `.zarr` output file. |
16 | 14 |
|
17 | | -## Deprecation policy |
18 | | - |
19 | | -Deprecations in the Parcels codebase between minor releases will be handled using the following 6-month timeline: |
20 | | - |
21 | | -- Functionality is marked for deprecation (e.g., in v2.1.0). This will include a warning to the user, instructions on how to update their scripts, and a note about when the feature will be removed. At this point the functionality still works as before. |
22 | | -- One minor release later (e.g., in v2.2.0), or at least 3 months later, the functionality will be replaced with `NotImplementedError`. |
23 | | -- One minor release later (e.g., in v2.3.0), or at least 3 months later, the functionality will be removed entirely. |
24 | | - |
25 | | -These changes will be communicated in release notes. |
| 15 | +## Changes in policies |
26 | 16 |
|
27 | | -Deprecations of classes or modules between minor releases will be avoided, except in the instance where it is deemed to have little to no impact on the end user (e.g., if the class/module was mistakenly included in the Public API to begin with, and isn't used in any user scripts or tutorial notebooks). |
| 17 | +- In v4.0.0 of Parcels, adopted EffVer which formalises this "SemVer-like" variant we were following - and we adjusted our deprecation policy. |
| 18 | +- In [v3.1.0](https://docs.oceanparcels.org/en/v3.1.0/community/policies.html) of Parcels, we adopted SemVer-like versioning and deprecation policies |
0 commit comments