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

If we want to have an stable branch(or branches) Some thinks will need to define are: Given that we break the compatibility very easy ( I think now is broken) maintain each version serie (1.1.x , 1.2.x., etc) will increase our maintenance efforts. Do we want to maintain every new release we do ? Or should we pick only one and define a time to be maintained (6 months , 1 yr)? Having more than one branch we maintain we will need to rework the packaging provision. - Does OBS supports multiples channels to have an stable or edge or testing? If not will need to create a new repository every time we do a new release? - Also will need to fix the packaging scripts to make them easy to package any kata version. Today is need to update the the scripts if there are new dependencies or new files provided in a package. - The same applies to snap, I think will be more easy to maintain this. - Carlos From: Boeuf, Sebastien Sent: Wednesday, July 18, 2018 1:24 PM To: Ernst, Eric <eric.ernst@intel.com>; Fox, Kevin M <Kevin.Fox@pnnl.gov>; Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz@intel.com>; akapoor87@gmail.com; rajudev <rajudev@disroot.org> Cc: kata-dev@lists.katacontainers.io Subject: RE: [kata-release] release cadence, process Yes, IIRC we agreed (during Arch Committee meeting) about releasing as much 1.1.X releases as we want since they will only include bug fixes. Now, on a side note, we'll hit the topic of creating a new branch when we'll have a change breaking the compatibility, but that we'll want to still get the bug fixes into new releases. That's where the complexity starts and where we need to decide about a backporting plan. Thanks, Sebastien ________________________________ From: Ernst, Eric [eric.ernst@intel.com] Sent: Wednesday, July 18, 2018 11:10 AM To: Fox, Kevin M; Venegas Munoz, Jose Carlos; akapoor87@gmail.com<mailto:akapoor87@gmail.com>; rajudev Cc: kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> Subject: Re: [kata-dev] [kata-release] release cadence, process 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<mailto:Kevin.Fox@pnnl.gov>> Date: Wednesday, July 18, 2018 at 11:09 AM To: Eric Ernst <eric.ernst@intel.com<mailto:eric.ernst@intel.com>>, "Venegas Munoz, Jose Carlos" <jose.carlos.venegas.munoz@intel.com<mailto:jose.carlos.venegas.munoz@intel.com>>, "akapoor87@gmail.com<mailto:akapoor87@gmail.com>" <akapoor87@gmail.com<mailto:akapoor87@gmail.com>>, rajudev <rajudev@disroot.org<mailto:rajudev@disroot.org>> Cc: "kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io>" <kata-dev@lists.katacontainers.io<mailto: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<mailto:akapoor87@gmail.com>; rajudev Cc: kata-dev@lists.katacontainers.io<mailto: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

Anne Bertucio wrote:

How many past versions we support is a balance between upstream community effort required and creating a user/operator-friendly project. Per Tim’s example on the Arch call, the average K8s user is not on the most current release, and in OpenStack the average user is typically N-2. While we want to encourage them to upgrade, it’s just not the operator reality.

In Vancouver, the game plan on release cadence was to switch to time-based releases for major and minor (x.0.0 and 1.y.0 respectively) as soon as we felt it was feasible. We agreed to lean on the Arch Committee to guide us to when that would be. I feel like having a handle on what our time-based cadence might be will help in evaluating the “upstream community effort required” piece of the puzzle. Any thoughts since Vancouver on what our cadence might look like?

A bit of generic advice from my experience doing release management on several openly-developed open source projects: Main release cadence is a trade-off between getting features out and the cost of releasing/upgrading/maintaining. On the "more often" side, you generally find developers wanting fast feedback on their development (release early, release often) and users waiting for a specific feature (especially in the early days of a project). On the "less often" side, you generally find people impacted by the action of releasing (release managers when releases are not fully automated, marketing teams doing communications), existing users needing to upgrade (when upgrade is not trivial) and stable release maintainers (more releases meaning more backporting work). If you manage to limit the release cost (by automating release management and limiting marketing release communications), reduce the upgrade cost (by making it dead easy to upgrade, skip versions or support multiple versions running alongside), then the only thing preventing you from releasing very often is the stable release maintenance. Stable release maintenance is a bit tricky, as in a lot of cases (like Kubernetes or OpenStack) deployers are years behind, and maintaining all branches for all releases leading up to that is painful (you basically have to backport bugfixes for all supported branches, and community volunteers for that job are not plenty). It also impacts automated testing, as you sometimes need to keep a lot of test nodes around to test those old branches. If you support upgrading from any version to any version, you can solve some of that using a LTS scheme. But if users have to go through every version to upgrade, the solution is to keep a relatively long release cadence and only support a handful of past branches. Now, I feel like Kata may have a unique profile here (due to where it runs and how it's upgraded) which may well support a rather aggressive cadence. Would it support upgrade from any version to any version ? Would you upgrade running containers, or just let the old version run alongside the new version ? Hoping this helps, -- Thierry Carrez (ttx)