-
Notifications
You must be signed in to change notification settings - Fork 169
LTS Release Process and Support
Laura, Jason R edited this page Jun 7, 2023
·
4 revisions
This page shows the steps on creating an LTS (Long Term Support) release and supporting older LTS versions.
Quick rundown of what LTS entails:
- An LTS release is a feature release tagged as
LTS
- An LTS release occurs every 12 months
- An LTS version is supported for at least 18 months before End of Life (EoL)
- At maximum two LTS versions to support concurrently
For a more in-depth overview regarding our LTS approach, check out RFC8 - ISIS Long Term Support.
- Tag the Feature Release as
LTS
**Note: Automation of Steps 1 - 3 is TBD. The PR in Step 3 will be manually reviewed and approved before merge.
- Any bugfix PR that addressed an issue with the
bug
label should have abug
label as well. - Manually update PRs with the
bug
label in preparation for the next step.
- Pick and choose the bugfix PRs that will be brought down into the LTS version.
- Create a PR and manually make the selected bugfixes by hand.
- Be sure to reference the bugfix PRs in the body of this PR.
- Merge the PR into the LTS version of interest.
- Increment the patch version of the LTS build.
- Release the newly versioned build via Anaconda.
- Further guidelines on the Public Release Process
- Building
- Writing Tests
- Test Data
- Start Contributing
- Public Release Process
- Continuous Integration
- Updating Application Documentation
- Deprecating Functionality
- LTS Release Process and Support
- RFC1 - Documentation Delivery
- RFC2 - ISIS3 Release Policy
- RFC3 - SPICE Modularization
- RFC3 - Impact on Application Users
- RFC4 - Migration of ISIS Data to GitHub - Updated Information 2020-03-16
- RFC5 - Remove old LRO LOLA/GRAIL SPK files
- RFC6 - BLOB Redesign
- Introduction to ISIS
- Locating and Ingesting Image Data
- ISIS Cube Format
- Understanding Bit Types
- Core Base and Multiplier
- Special Pixels
- FAQ