RFC 14: Changing in ISIS release Schedule

[Kelvinrr]

• Feature/Process Name: Changing in ISIS release Schedule
• Start Date: 2/15/25
• RFC PR:
• Author: Kelvin Rodriguez

Summary

Change the ISIS release schedule to reduce the cadence of production releases and automate dev and LTS releases.

Motivation

The ISIS release process is unnecessarily complicated, largely manual, and the release cadence is unnecessarily fast as identified in the ISIS TC meetings.

This causes several issues:

1. Releasing ISIS currently takes 1-2 weeks for 1-2 developers after every support sprint, this is compared to a 3 week support sprint.
2. The complexity and manual nature makes it prone to error, combined with the high cadence, it reduces the stability of the production releases.
3. API breaking changes need to stay in a PR, left unused, for up to a year. Merging them after non-API breaking features are merged further complicates maintenance.

By moving to automated releases and reducing the cadence on manual production release, we can save significant amount of developer hours per year which can be used to develop and polish new features such as cloud optimized geotiff support.

Proposed Solution / Explanation

I propose the following changes:

1. Use AWS CI/CD to deploy a development build of ISIS on some regular cadence (e.g. weekly, biweekly) that users can download to test new features.
2. Use AWS CI/CD to automatically deploy LTS changes as bug fixes go in during support work
3. Change the cadence of production releases to once a year.

This has the following benefits:

1. Allows API breaking features to be merged and deployed ASAP.
2. Gives users a better chance to use new features before deploying to production.
3. Saves thousands of dollars in developer time.
4. Creates builds for those who wants the latest features (dev), maximum stability (LTS) and regular users that just want the latest production version.

What will NOT change:

1. LTS is still going to be maintained at a similar cadence.
2. New production releases still use the release candidate (RC) cycle
3. Version bumps will still use semantic versioning.

Diagram showing the proposed release cadence, note biweekly here is just an example as we would run a continuous delivery script on a schedule.

Drawbacks

1. Some people might prefer the higher production cadence instead of a dev build.

Future Possibilities

• "one liner" download script that can install either dev, LTS or production versions of ISIS
• More aggressively merge in sweeping changes to make ISIS more cloud native

[oleg-alexandrov]

Frequent automated builds and less frequent labor-intensive manual builds sounds reasonable.

It would be good if the documentation also keeps up with the build. That does not looks easy to do given the doc at https://isis.astrogeology.usgs.gov/.

[Kelvinrr]

Current docs are: https://astrogeology.usgs.gov/docs/how-to-guides/software-management/public-release-process/

Definitely not easy to follow. Even people who were involved in originally conceiving this process had a hard time following it, so I decided to rework the whole thing.

[oleg-alexandrov]

I was thinking more of the user-facing docs. Ideally the manual is kept-up-to-date with the build, and it is clear which is the stable doc and which is latest doc.

Good you have documentation for developers too, can be of great help.