Officially Supported Technologies
This list of Approved Technologies is intended to guide developers in choosing technologies that the FOLIO Technical Council has acknowledged to be compatible with the FOLIO project's existing architectural and operational requirements.
Given practical concerns it is not intended that this list be comprehensive, and it should be expected that this list will grow and change over time. Proposed changes should be communicated to the TC, who will serve as the maintainer of these lists.
Each document in this section will be tracked by the following statuses:
STATUS | ALLOWABLE CHANGES | APPLIES TO NEW MODULES | TARGET RELEASE |
|---|---|---|---|
DRAFT | Security, 1st party, third party | NO | Future |
ACCEPTED | Security, 1st party only | NO | Future |
ACTIVE | Security, 1st party only | YES | Current Flower Release (In support)
|
ARCHIVED | NO | NO | Past Flower Release(Out of support) |
Communication Plan
As changes are made to these lists of Officially Supported Technologies, the changes need to be communicated to interested parties. The following list of slack channels (or subset of the following) should be used:
#sys-ops
#development
#folio-implementers
#product-owners
#folio-community-council
#folio-product-council
#releases
FOLIO Releases
Timing of Upkeep Activities
When release cycle milestones are published, the TC should plan the following activities (e.g. put them on the calendar / meeting agendas / etc.). See Example TC Actions table below.
When a release is GA, the TC should create the DRAFT for the release after the next (if it doesn't already exist)
The TC should transition DRAFT pages to ACCEPTED for the next release prior to its release scope composition deadline. The TC should start reviewing the draft in the weeks leading up to this milestone.
The TC should transition ACCEPTED pages to ACTIVE when development begins on that release (i.e. around the feature development freeze for the current release cycle.)
ACTIVE transitions to ARCHIVED when the release goes out of support
Example Cycle for Quesnelia (Release 'X') OST Page
These dates occur during several different development cycles, but all affect the Quesnelia OST page.
Date | Triggering Event | Date Listed on | OST Page Action |
|---|---|---|---|
2023-04-10 | Orchid (X - 2) becomes GA. | The Orchid (X - 2) release page | TC creates the DRAFT page for Quesnelia |
2023-09-08 | Quesnelia (X) release scope composition deadline | The Poppy (X - 1) release page | TC transitions Quesnelia from DRAFT to ACCEPTED |
2023-10-06 | Poppy (X - 1) feature development freeze | The Poppy (X - 1) release page | TC transitions Quesnelia from ACCEPTED to ACTIVE |
2025? | Sunflower (X + 2) becomes GA | The Sunflower (X + 2) release page | TC transitions Quesnelia from ACTIVE to ARCHIVED |
Example TC Actions during Quesnelia ('X') Release Cycle
These dates are all listed on the Quesnelia page & occur during its development cycle, but affect several different OST pages.
Date | Triggering Event | OST Page Action |
|---|---|---|
2024-02-16 | Ramsons (X + 1) release scope composition deadline | TC transitions Ramsons (X + 1) from DRAFT to ACCEPTED. |
2024-03-15 | Quesnelia (X) feature development freeze | TC transitions Ramsons (X + 1) from ACCEPTED to ACTIVE |
2024-04-29 | Quesnelia (X) becomes GA | TC transitions Orchid (X - 2) from ACTIVE to ARCHIVED and TC creates the DRAFT page for Sunflower (X + 2) |
Open Questions:
Do we want a single status for the current release + releases still in support periods? Or do we want multiple status for these?
Do we even need status at all? Can we instead lean on the approval/review dates?
What exactly does the process look like?
In terms of "communicating changes to the TC
wrt workflow/state transitions
etc.