| 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 8)
- 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 - do 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.
|