Assuming that the release isn’t changing any APIs, etc. If its just a bug fix, it would allow this.
If any incompat is introduced it’d be a 0.x.0 update.
--Eric
From:
"Fox, Kevin M" <Kevin.Fox@pnnl.gov>
Date: Wednesday, July 18, 2018 at 11:09 AM
To: Eric Ernst <eric.ernst@intel.com>, "Venegas Munoz, Jose Carlos" <jose.carlos.venegas.munoz@intel.com>, "akapoor87@gmail.com" <akapoor87@gmail.com>, rajudev <rajudev@disroot.org>
Cc: "kata-dev@lists.katacontainers.io" <kata-dev@lists.katacontainers.io>
Subject: RE: [kata-release] release cadence, process
Based on your 0.0.x comment, I think I know, but am verifying...
This would still allow upgrading some components while running older components on the same host?
Thanks,
Kevin
From: Ernst, Eric [eric.ernst@intel.com]
Sent: Wednesday, July 18, 2018 10:59 AM
To: Venegas Munoz, Jose Carlos; akapoor87@gmail.com; rajudev
Cc: kata-dev@lists.katacontainers.io
Subject: [kata-dev] [kata-release] release cadence, process
Carlos et al,
I am proposing that we continue to roll releases; we are having a good amount of fixes merge and I think it warrants having a regular weekly cadence (likely a 0.0.x update). I believe we discussed this before – let’s start driving it.
Carlos, Raju, Akshay – from prior emails/request for volunteers, you were all listed for folks to help with packaging and release. Carlos, is the process defined enough that you think we can start rotating the release duties among more stakeholders?
WDYT?
Thx,
Eric