Susan Bowen (HPE), Jonas Arndt (HPE), Louis (LF), Alex Vul (Intel), Piotr Zedlewski (Inte), Bob Monkman (Intel), 



Release Management discussion

  • Returned to the question of whether to have maintenance releases.
  • Decisions relating to the frequency of releases and whether to have major and maintenance or a different strategy:
    • How far back do we support?
    • How to name/number the releases.
    • Branching strategy.
    • Snapshot releases.
  • Supporting previous versions
    • Proposal: Don’t create maintenance releases and backport them.
    • For other projects that do maintenance releases, they are tied to one specific major release.
  • How to name/number the releases
    • Could use numbers, but make them 1.0 for a major release, 1.01 for small change, then the next big release becomes 2.0.  (new feature or improvement or evolution)
    • Could use code names for releases, such as “city” Then if there is a maintenance release it is described as “maintenance release for (name of) city release.”
    • Could use the last two digits of the year and two digits for the month, so a release in January of 2021 would be called “21.01”   A point release a month later would be called “21.01.1”
    • Piotr Zedlewski also described
    • the SPDK project strategy, which specifies LTS (Long Term Support) releases. Its numbering is “2.1.0 LTS release”. Once a year with a maintenance release. Links:

From Piotr Zedlewski (Intel) to Everyone:  09:22 AM

Storage Performance Development Kit

  • Branching Strategy
    • The Git branching model:, Includes Main branch, Dev Branch, Feature Branches. (see chart)
    • Different branches, different streams by function (telemetry, eventing as examples). When one of the new branches becomes stable, it goes into the release train.
    • The SPDK project has only the main and release branches. Concern there is developing the new and experimental and doing them directly in the release branch.
    • Experimental work (new features/functions) should never break the existing release (main branch).
    • Desire for ODIM to get to a loosely coupled Get to open stack model of self-certification (Alex) need to get to that. Rigorous (API tests passed – this will fall onto the dev team).
    • Common core with supporting services ODIM relies on.  Loosely coupled and pluggable is good – better off the project will be.  Rafal and Alex want to talk about how to make it modular and loosely coupled for future expansion – they would have people dedicated to doing that work.
    • You should be able to clone from main branch with confidence

  • Snapshot releases
    • When a new feature/function branch becomes stable, it goes into the release train.
    • There is ongoing CI CD and no maintenance releases. Releases that are a snapshot.

9:40 am TOPIC: TSC PROPOSAL MEETING scheduling

  • Tuesdays from Pacific 6 am to 7 am
  • 21st and 28th
  • Meet first week of 2021 (release Jan 31st!)

9:50 TOPIC: Move under umbrella

  • CNCF - Sandbox project? (Would ODIM ever get out of that?)
  • Martin, when discussion with CNCF it may never become a qualified project. They didn’t have resources to review sandbox projects and make ODIM a regular (qualified) project.
  • Alex, we need to do the homework. If CNCF develops an alternative bare-metal toolkit.
  • Ran out of time

9:58 LFN and LFE? (Louis said) wherever home for ODIM

Meeting Recording

Chat File

  • No labels


  1. Where do we have recording from this TSC session?

  2. Yeah I don't know. Louis usually posts them within a day....