What is in scope?

Upgrades to any of the Officially Supported Technologies

Terminology

FOLIO distribution - All deployable artifacts produced by the FOLIO community and included in a flower release, e.g. jar files, docker images, JS bundles, vagrant boxes
Infrastructure Components - Components that are required to run, build FOLIO but are not packaged with the FOLIO distribution
Non Infrastructure Components - Components that are a part of FOLIO distribution
LTS - Long Term Support

What is out of scope?

Process for Introducing new components to the platform. ADR/RFC process is in place for such cases.
Deciding what makes is part of Officially Supported Technologies and what is not
Resource planning for upgrades

Objectives

Ensure third-party component usage is consistent across teams
Ensure that the FOLIO platform consistently uses component versions that are in LTS
Ensure that fixes to known CVEs are incorporated in a timely manner
Ensure that the development/operational aspect of making the upgrade is well planned

Assumptions

TC can delegate any of the work related to upgrades to that security group or a sub-group as it sees fit.
If the decision to upgrade fits the ADR criteria, document the decision as an ADR
While it is good to have some time-bound expectations, it is not very clear that it is something that can be enforced practically. That said, this process is expected to work based on an honor system. Teams should try and adopt these guidelines and realize that this will result in the community building a robust platform

Process Overview

Documenting Usage

Happens Once a year
Teams/individuals are expected (could be a gating factor during a release) to document their usage of tools/frameworks/dependencies by filling out the following information. Teams can also flag libraries that are going out support for a variety of reasons in the next 6-9 months
Information collected is expected to be submitted to the TC
The TC reviews the data for compliance by checking if any of the app/module is using an unsupported version
If the data reveals a certain module/app is using unsupported versions, the team owning the module/app is expected to address the issue within 6-9 months

Audit Template

Common

Infrastructure	Version
Kafka
OpenSearch
Postgres
Maven

Frontend Apps

App Name	React	Yarn	npm
Stripes Platform

Backend Modules

Module Name	Java	React	Yarn	npm	Junit	Spring Boot	Vertx
okapi
mod-inventory

Upgrade Scenarios

TC-driven

Applies to the situation where the TC recommends an upgrade to keep up with changing versions
TC monitors the release of new LTS version as they become available and recommends teams to schedule an upgrade within 6-9 months of the LTS release
TC works with the team to establish an upgrade plan

Team-driven

Applies to the situation where the team is in need of a particular version to take advantage of some new feature, performance enhancements, or a bug fix
The team will present the proposal to the TC that includes the upgrade plan
The proposal can be presented to the TC in one of the weekly meetings
TC will review the proposal and make edits as needed
The team works with the stakeholders to schedule this upgrade

Security-driven

Applies to the scenario where libraries needed to be upgraded to address a major critical security vulnerability
TC will work with all affected teams to establish a timeline for rolling out the fix to the CVE

Upgrading Infrastructure vs. Non Infrastructure Components

Infrastructure Components

Given the constraints the community has on testing the platform on multiple versions of supported infrastructure components, support will be limited to just one version of the infrastructure component, at any given time.
Service providers can proceed to use unsupported versions at their own risk
Intent for upgrading an infrastructure component MUST be submitted as a proposal (MUST include justification) to the TC at least one release cycle before the intended upgrade
TC deliberates the proposal with all relevant stakeholders to arrive at a consensus. The proposal can ONLY move forward when consensus is reached among the stakeholders (e.g.hosting providers, implementors, systems operators, DevOps)
In the event the proposal to upgrade moves forward, plans should be put in place to execute it in the next release cycle. Teams should consider making this upgrade very early in the release cycle to give teams enough time to execute all available regression test suites

Note :

In the case when discussions related to the upgrade is not resulting in a consensus, steps should be taken to resolve the situation as soon as possible. Everyone should realize that protracted discussions around upgrades will certainly hold back the community in terms of technological advancements to the platform

Non Infrastructure Components

Intent for upgrading an non infrastructure component MUST be submitted as a proposal (MUST include justification) to the TC
Teams will decide their own timeline for upgrading non infrastructure components. However, teams SHOULD not vary from the supported technology list for major components.
Timeline for deprecating usage of older versions should definitely be considered while making plans for the upgrade
In the event of any upgrade affecting build/infrastructure pipeline, the DevOps (as they might the first to see) team will communicate the impact to the developer community

Upgrade Plan

Upgrade Instructions
Breaking Changes/ Known Issues/Incompatibilities
Components Affected
Rollback Instructions
Regression & Performance Test Plans

Questions?

Who will work on the resource plan when the upgrade initiative is TC driven?
Do we have reserved capacity to address tech debt items in each release?
Who are the stakeholders for the upgrade plan and how do we communicate it?
How tight the constraints needs to be? TC has to be involved more. Is it worth ?

Browser not supported