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)

  • Being developed/in progress
  • Latest release in production
  • Previous release

ARCHIVED

NO

NO

Past Flower Release(Out of support)

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

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.

DateTriggering EventDate Listed onOST Page Action
2023-04-10Orchid (X - 2) becomes GA.  The Orchid (X - 2) release pageTC creates the DRAFT page for Quesnelia
2023-09-08Quesnelia (X) release scope composition deadline The Poppy (X - 1) release pageTC transitions Quesnelia from DRAFT to ACCEPTED
2023-10-06Poppy (X - 1) feature development freezeThe Poppy (X - 1) release pageTC transitions Quesnelia from ACCEPTED to ACTIVE
2025?Sunflower (X + 2) becomes GAThe Sunflower (X + 2) release pageTC 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.

DateTriggering EventOST Page Action
2024-02-16Ramsons (X + 1) release scope composition deadlineTC transitions Ramsons (X + 1) from DRAFT to ACCEPTED.
2024-03-15Quesnelia (X) feature development freezeTC transitions Ramsons (X + 1) from ACCEPTED to ACTIVE
2024-04-29Quesnelia (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.