| Discussion on Tech Council's recommendations for Release Management | Mike Gorrell | - https://docs.google.com/presentation/d/1GewE9fPgasE9pDFdjsDSjxIizYJvBSOm10TJksmnyiU/edit
- Q - release numbers are related to FOLIO as a whole as opposed to the releases of individual modules?
A - platform level - First LTS would be after MVP. we haven't hit the 1.0.0 release for FOLIO as a whole yet. - Q - How long do we support the back porting of security issues?
A - between 2-4 years Current major release and previous major release - Tod - two years between LTS releases is a little long - maybe make it 12 months. Imagining the solid green is development, then dotted line for security releases for another portion into the next LTS. (see amended slide 7)
- Support for 12 month LTS releases?
- Q-upgrade from LTS 1.0.0 to 2.0.0 would be an expected upgrade option?
A - yes - Q - Flower names are for pre-production releases?
A - We would continue flower names, but would be tagged as an LTS. - Grants some flexibility
- Upgrade paths from LTS releases expected - if you want to go from 1.2.0 to 2.0.0 - you have to upgrade to 1.3.0 first
- Upgrade paths from each major release to each minor release
- Security releases for 6 months - is that too short a time?
- The security releases for the previous LTS would allow time for upgrade planning
- Shortening release cycle from 24 months to 12 months makes it a max of 24 months per release for security updates.
- Upgrades often happen in the summer. If a major release comes out in January, it won't be in production until the summer for most institutions.
- Data restructuring should be considered as LTS instead of minor releases.
- At WOLFcon, we discusses making it clear that these releases are at the platform level, not at the module level. Breaking changes for individual modules may or may not be contained in major releases.
- Having the numbers for releases was to try to clarify between major/minor/maintenance releases.
- Amended slide now includes intended migration paths.
- Thinking as a PO - whenever a fix is produced, noting where it gets deployed to is going to be important
- Talking about release numbers...Instead of using the 1.2.0, name them according to the year and quarter LTS = 2020 or 2021, then Q1 Do we want the major releases done in January? Or in May?
- We already have 2 ways we refer to releases, flower name and year.quarter. Can we continue to use those names and annotate the LTS versions? "Fameflower 2020 Q1 - LTS release" and let that be our versioning?
- First major release is semantics at the moment at some point we'll put a stake in the ground and call it a major release.
- Fiscal year is a year ahead, hardware is named for current year.
|