RFC8 ISIS Long Term Support - Discussion

[jessemapel]

This issue is for discussion of RFC8 proposing the addition of long term support to some ISIS releases.

[jessemapel]

The original request for user stories about this can be found here:

planetarysoftware/ISIS_TC#124

[jlaura]

@jessemapel I think that the RFC looks quite good and provides an appropriate amount of information to help drive this conversation forward. I am going to suggest that this RFC not be adopted unless a few additional issues can be resolved:

1. We need a commitment from our large user groups that they will be adopting these LTS versions. Otherwise, we will be in a position like we are now now where we generate Release Candidates that are largely unused. To say this another way, I do not believe we should adopt any change to the release cadence unless we have a reasonable expectation that we will have first followers that will adopt keeping their work in sync with this cadence. As you note, this release process adds complexity. It also needs to add value to users that are using it, not just from a conceptual perspective.
2. We need additional feedback on this issue. The RFC clearly took an appreciable amount of time to develop. The ISIS TC issue that you linked shows some good preliminary discussion, but we need broader community input before adopting this RFC. I believe that the TC can and should help to gather that feedback. I would suggest this RFC remain open until feedback has been received and incorporated from users, TC members, committers, etc.
3. We need answers to the questions that you posed at the end of the RFC from all contributors as answering these questions bounds the level of effort to implement LTS. So, I disagree with the RFC here that these can wait until implementation to answer.

Now some of my thoughts on your questions:

There are a handful of questions related to this proposal:

Does this change impact the Release Candidate process?
Do we need more testing for LTS releases vs regular releases?

I agree with the implication of waiting to discuss these two questions until implementation, but believe that we need to answer them because of the unspoken expectations of an LTS. In my opinion, an LTS does not imply some highly tested, known to absolutely bug free release. It is simply a tag or label that says, we will make every reasonable effort to port bug fixes into this version until EOL. The scope of work to do that is known. From the ISIS TC discussions, the expectation seems to be that an LTS is somehow tested more vigorously. I see two options here:

• Make every non-LTS release an RC (so release once per year in January using the RFC calendar) and have wide adoption of the RC releases by users that have stability concerns (e.g., missions) to help build some sense of trust in the stability of the software.
• Engage users more heavily to provide and help writing unit, functional, and integration tests. We need user engagement because the core contributors on this project (a) do not use the code in production at the same scale, (b) already write large quantities of tests (ISIS is heavily tested in many areas) and it is unrealistic to assume that one users use case is an area a core contributor even knows is lacking testing, and/or (c) do not have access to the cross library pipeline that is somehow causing an issue.

Do we want to change our versioning to be based on LTS releases and not semantic versioning?
Without a compelling reason to do this, I would say no. Semantic versioning with LTS releases provides a lot of information to a user in a very small package.

• 6.2.1 LTS - tells me major version stability, second feature release, fist bug fix, and EOL/backport bugs until DATE.
• LTS1 - tells me this is the first LTS with an EOL of DATE.

Apologies this is lengthy. The topic is complex and requires broad discussion beyond just TC members.

[jessemapel]

Moving to a discussion #4691