Open Stack

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 at intel.com>; Fox, Kevin M <Kevin.Fox at pnnl.gov>; Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz at intel.com>; akapoor87 at gmail.com; rajudev <rajudev at disroot.org>
Cc: kata-dev at 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 at intel.com]
Sent: Wednesday, July 18, 2018 11:10 AM
To: Fox, Kevin M; Venegas Munoz, Jose Carlos; akapoor87 at gmail.com<mailto:akapoor87 at gmail.com>; rajudev
Cc: kata-dev at lists.katacontainers.io<mailto:kata-dev at 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 at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>>
Date: Wednesday, July 18, 2018 at 11:09 AM
To: Eric Ernst <eric.ernst at intel.com<mailto:eric.ernst at intel.com>>, "Venegas Munoz, Jose Carlos" <jose.carlos.venegas.munoz at intel.com<mailto:jose.carlos.venegas.munoz at intel.com>>, "akapoor87 at gmail.com<mailto:akapoor87 at gmail.com>" <akapoor87 at gmail.com<mailto:akapoor87 at gmail.com>>, rajudev <rajudev at disroot.org<mailto:rajudev at disroot.org>>
Cc: "kata-dev at lists.katacontainers.io<mailto:kata-dev at lists.katacontainers.io>" <kata-dev at lists.katacontainers.io<mailto:kata-dev at 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 at intel.com]
Sent: Wednesday, July 18, 2018 10:59 AM
To: Venegas Munoz, Jose Carlos; akapoor87 at gmail.com<mailto:akapoor87 at gmail.com>; rajudev
Cc: kata-dev at lists.katacontainers.io<mailto:kata-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180718/dbffa511/attachment-0001.html>