From 63bdef3ec098248d589a968fabeffccd216fc0eb Mon Sep 17 00:00:00 2001 From: Sherwin-14 Date: Fri, 12 Jul 2024 22:27:23 +0530 Subject: [PATCH] Added documentation page for backwards compatability This PR is aimed at solving the issue no `closes #471` --- CHANGELOG.md | 3 ++ docs/user_guide/backwards-compatibility.md | 45 ++++++++++++++++++++++ 2 files changed, 48 insertions(+) create mode 100644 docs/user_guide/backwards-compatibility.md diff --git a/CHANGELOG.md b/CHANGELOG.md index 882538ea..e7148781 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -26,6 +26,9 @@ - Add support for Python 3.12 ([#457](https://github.com/nsidc/earthaccess/issues/457)) ([**@chuckwondo**](https://github.com/chuckwondo),[**@mfisher87**](https://github.com/mfisher87)) +- Added documentation for the backwards compatibility + ([#471](https://github.com/nsidc/earthaccess/issues/471)) + ([**@Sherwin-14**](https://github.com/Sherwin-14),[**@mfisher87**](https://github.com/mfisher87)) ### Removed diff --git a/docs/user_guide/backwards-compatibility.md b/docs/user_guide/backwards-compatibility.md new file mode 100644 index 00000000..1e104408 --- /dev/null +++ b/docs/user_guide/backwards-compatibility.md @@ -0,0 +1,45 @@ +# Our commitments to backwards compatibility + +We care deeply about minimizing negative impacts of changes to earthaccess, but we also care deeply about making earthaccess the most valuable it can be to our users. These are sometimes in conflict, and this documentation helps us make decisions that balance these needs in a way that's best for our users. + +## Our versioning scheme + +We use [SemVer](https://semver.org/) to tell you what to expect when upgrading. We recommend following the link to learn more, but here are the important ways this affects you: + + 1. There are 3 version parts: MAJOR.MINOR.PATCH (e.g. 1.2.3 is major version 1, minor release 2, patch release 3). + 2. When the major version changes, anything can break! Always visit this documentation before doing a major upgrade. + 3. When the minor version changes, new features should be available, but nothing should break. Visit the documentation to learn about new features. + 4. When the patch version changes, only bugfixes should be included. Visit the CHANGELOG to learn more about the fixes. + +## Our commitments + +### Versioning + +We will follow SemVer. All version changes will consider [this](https://example.com/our-public-api) to be the public API documentation for the purposes of deciding whether a change is breaking or non-breaking. + +### Release Communication + +1. We will announce releases on the following channels: ___ +2. Release announcements will include a prominent notification of breaking changes, including a link to migration guide. + +### CHANGELOG + +1. We will update the CHANGELOG for every release +2. The CHANGELOG will include prominent notification of breaking changes, including a link to migration guide. + +### Fixing Backwards Incompatible Changes + +1. We will plan to fix any backwards incompatible changes in non-major releases. + +2. We cannot guarantee developers will be available to complete this work alongside other priorities. + +3. Our maintenance team will always welcome outside contributions towards this goal. + +4. Please use an issue to communicate about this work. + +## Migration guides + +Under Development 🚧 + +This section will contain migration guides for future releases. Check back soon for updates! +