RC8 Long Term Support #4691
Replies: 13 comments 2 replies
-
|
See previous discussion on the old issue #4653 In particular @jlaura wrote a good response from the development perspective: #4653 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Here is my previous comment for easier discussion over here: @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:
Now some of my thoughts on your questions:
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:
Apologies this is lengthy. The topic is complex and requires broad discussion beyond just TC members. |
Beta Was this translation helpful? Give feedback.
-
|
We have discussed this proposal at HiRISE and support it. Our intention would be to update to the latest LTS version on a yearly basis. We also acknowledge that there will be events outside of our control that may delay our adoption of the latest LTS version. As our mission ages, we can expect decreased funding and workforce and increased demands. We welcome a more deterministic release schedule and believe it will facilitate us keeping up with updates and fixes by allowing us to plan ahead for testing and adoption. We also appreciate the stability that a LTS version provides. As a mature mission stability is important to us. Should this proposal be adopted, we commit to making our best effort to stay up to date with the latest LTS version. |
Beta Was this translation helpful? Give feedback.
-
No. I agree with Jay here, Semantic versioning provides a robust set of information, and whether a particular release is an LTS release or not is just an extra attribute of that release. |
Beta Was this translation helpful? Give feedback.
-
|
LROC is in support of this LTS model and recognizes its benefit to mature missions using ISIS. In order to adopt the LTS model, we would like clear language to be included regarding the 30-days before the planned release as the cutoff period to have a feature merged, as was mentioned in TSC meetings. As we understand it, a feature would have to be merged greater than or equal to 30 days prior to the next LTS release in order to guarantee it is included in the next LTS release. This is vital to our development planning since we would be like any submitted features included in the next release to be adopted, especially since we would be working off of that version for at least 12 months. LROC would also like to work with the ASC developers to learn how to streamline the submission process and identify any opportunities to reduce the overall time it takes to merge mission submitted features and/or bugs. This would help to successfully adhere to the LTS release schedule and overall contribution to the code-base from the LROC team using this model. |
Beta Was this translation helpful? Give feedback.
-
|
LROC would like to keep normal semantic versioning. |
Beta Was this translation helpful? Give feedback.
-
|
Same for HiRISE. |
Beta Was this translation helpful? Give feedback.
-
|
Based on the discussion at the 2.10.22 ISIS TC meeting, the LTS will not guarantee any supplement testing above and beyond the normal testing done for a release (automated testing using CI). |
Beta Was this translation helpful? Give feedback.
-
|
I've added Release Candidates to the example release schedule and removed the questions as this would have no impact on release candidates. Every quarterly release, LTS or not, would still have a release candidate one month out. Any code changes submitted before the release candidate is pulled will be included (code is frozen a month out from each release). |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for bringing up this question. For a sporadic ISIS user like me, an even longer release cycle is attractive, such as a new LTS release every 24 months and support for 5 years. Nowadays laptops and workstations easily last 5-10 years, and having to install ISIS only once on each machine would be naturally efficient. I noticed that the complexity of ISIS installations has increased. It used to be just rsync; now its conda + mamba + rsync. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately we can't maintain our environments for such a long time. The 1-1.5 year duration was decided upon because it is something we can reasonably maintain without drastically growing our support and maintenance efforts. You should still be able to work with very old versions of ISIS, you just won't receive bug fixes for them. |
Beta Was this translation helpful? Give feedback.
-
|
There have been no further significant comments on this RFC so I am going to close it out in two weeks on May 2nd 2022. |
Beta Was this translation helpful? Give feedback.
-
|
Per the TC meeting, The data directory per LTS version will be synced with the main (non-LTS) data directory unless a new mechanism is introduced that used new data items for said mechanism. These data will not be automatically synced. Please correct me if I'm off base. |
Beta Was this translation helpful? Give feedback.
-
|
Closing this as there have been no further significant comments |
Beta Was this translation helpful? Give feedback.
-
|
Update based on implementation and discussion at the ISIS TC meeting. The plan is for the LTS RC to be created by the end of April, 2023. This will be version 8.0.0.
|
Beta Was this translation helpful? Give feedback.
-
Summary
A proposal for a new Long Term Support (LTS) model for ISIS releases. If accepted, every 12 months a new LTS version of ISIS will be released. The LTS version will receive bug fixes and critical security updates but no feature additions or breaking changes. When a new LTS version is released, the previous LTS version will be supported for 6 more months before it reaches End of Life (EoL). Each LTS version will be supported for at least 18 months. The following diagram gives an overview of what this could look like.
Motivation
The current ISIS release process is a quarterly feature release with bug fix releases into the latest feature release. This process has been successful at rapidly getting code changes released and available for users, but more rapid releases has come with new challenges.
First, the user base has become split across more versions of the software. Users are generally using the latest release for day-to-day work. For larger projects, users are sticking with a single version that they chose at the start of the project and then infrequently updating. The speed at which users update varies with some users updating every few months and others updating every few years. More rapid releases created a barrier to choosing which release to target for upgrades; there are too many options that do not appear distinct.
Second, each feature release only receives bug fixes for 3 months. If a user is working with a version of ISIS that is older than 3 months and discovers a blocking bug, reports it, and the developers fix it; that user must accept new feature changes and potentially breaking changes to continue their work. For day-to-day work, this is usually not a problem, but for large projects that involve extensive processing, the effort needed to upgrade grows rapidly.
Proposed Solution / Explanation
To alleviate these problems, we propose adding Long Term Support to one feature release each year. Long Term Support (LTS) for a release means that bug fixes and major security fixes are backported to that release for the duration of its support. Feature releases that receive Long Term Support are called LTS versions. The development environment, test data, and data area are also maintained for LTS versions. Each LTS version will be supported for 18 months so that there is a 6 month overlap between LTS versions. When support ends, the LTS version will be End of Life (EoL) and no longer receive bug fixes or major security fixes. During the overlap between LTS versions, users can upgrade and any bugs in the new LTS version can be fixed prior to the previous LTS version's End of Life (EoL).
This provides two release channels: a quarterly feature release that allows users to quickly get the latest changes to the software and an annual LTS release that users can plan larger projects and upgrades around. The user community can more easily share testing and bug reports are more consistent because more users are on the same version of the software. Users can also plan their projects and software upgrades around a slower annual cycle while still receiving fixes for any bugs they encounter.
If a bug fix is too onerous to backport to an LTS version, then the developers may label it as not being back ported. This is used only in extreme circumstances and can be re-evaluated if the bug fix has significant importance. The lifetime of LTS versions has been chosen to minimize the need for this, but because development time is limited and changes between future versions are mostly unknown, some exceptions are allowed. If a bug fix is not backported to an LTS version, it will be noted in the release notes for the next release.
Additionally, if there have not been significant changes in the software, an LTS version can be postponed for up to 1 year. If this happens, the support for the current LTS version will be extended until 6 months after the postponed LTS version is released. An LTS version cannot be postponed within 3 months of its expected release.
The table below gives an example release schedule
Example Release Schedule
Drawbacks
The largest drawback to adding LTS is complexity. Users need to know about the LTS versions and understand what LTS includes. Developers need to support 2 to 3 versions of the code base and the accompanying environments. This adds friction to the installation, support, and development processes.
Adopting LTS will only help a subset of the user community. For users who keep up with the current update schedule this adds no value. On the other end of the spectrum, users that cannot maintain an annual upgrade pace will receive more support but will still be using an unsupported version of the software for some amount of time.
Maintaining the development environment for LTS versions is potential a big challenge. ISIS has many dependencies and since transitioning to using Anaconda, they are updated more frequently. Because dependencies are not controlled or distributed by the development team, we cannot guarantee that the installation and development environments that Anaconda installs will remain fixed for the lifetime of an LTS version. This could require additional changes to an LTS version to ensure the environments still work the same as when the LTS version was first released.
Alternatives
Long Term Support is the standard release and support model for foundational software like operating systems, compilers, and languages. The only alternative broadly used is the current ISIS release policy where releases are supported until the next release. So, the only major alternative is not doing anything. This does seem tenable and will leave a good amount of the user base with significant challenges.
There are some alternatives for tweaking numbers. Many software projects provide longer LTS lifetimes or even multiple concurrent LTS versions. These numbers were chosen based on the current funded support levels for ISIS. As the LTS lifetime gets longer, backporting becomes much riskier and more challenging. Similarly, with more concurrently supported LTS versions, development time increases and maintenance overhead grows. If support for ISIS grows and the community needs it, these numbers can be re-evaluated in the future.
Unresolved Questions
There are a handful of questions related to this proposal:
None of these are stopping this proposal from moving forward and they can be answered during or after implementation.
Future Possibilities
The largest follow up to this proposal is moving to continuous deployment. We already have continuous integration for ISIS, so continuous deployment is the obvious next step. If we do move to continuous deployment does that impact long term support or just the release in between LTS versions?
Beta Was this translation helpful? Give feedback.
All reactions