From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: RFC: LTS and stable release scheme Date: Tue, 6 Oct 2015 13:57:26 +0100 Message-ID: <5613C536.9030104@citrix.com> References: <20151006110758.GV29124@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZjRoC-0000ir-6m for xen-devel@lists.xenproject.org; Tue, 06 Oct 2015 12:57:32 +0000 In-Reply-To: <20151006110758.GV29124@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , xen-devel@lists.xenproject.org Cc: jgross@suse.com, Lars Kurth , netwiz@crc.id.au, Ian Campbell , George Dunlap , Andrew Cooper , Ian Jackson , Jan Beulich , cardoe@cardoe.com List-Id: xen-devel@lists.xenproject.org On 06/10/15 12:07, Wei Liu wrote: > Hi all > > A majority of developers express interests in trying a shorter release > cycle -- to change from 9 months to 6 months [0]. There are, however, > repercussions on how we manage stable and possible LTS releases. > > I start this thread hoping it's clearer that downstream consumers like > distributions and individual packagers can voice their opinions. I've > CC'ed some people I can think of who might be interested in this topic. > Feel free to CC more people. > > We don't have LTS scheme at the moment. Let me start with current > scheme for stable releases. > > - Release from xen-unstable every 9 months. > - Maintain last 3 releases as stable releases. > > So in effect, every stable release is maintained for at least 27 > months. > > When we switch to 6 months release cycle, if we stick with the same > scheme (last 3 releases as stable releases), every stable release is > only maintained for 18 months. It's too short for downstream > consumers. > > Ian proposed a scheme [1] in reply to [0]. In short, that scheme > proposes we pick every Nth release as LTS. He also proposed N=4 in the > case of 6 months release cycle. > > (FWIW I think N=4 is a sensible suggestion.) > > I can think of some open questions. > > 1. How long should each LTS release be maintained? > > Here are my two cents, there are two fundamental criteria for deciding > how long a LTS is supported: a) it can't be shorter than what we > already have (27 months); b) at any given time there must be at least > one LTS release available to downstream. > > With these in mind and N=4, I would say supporting LTS for at least > 2.5 years (5 release cycles) should be the minimal requirement. As for > the upper limit, I don't know. Linux has LTS supports ranging from 2.5 > years to 5.5 years [2]. Another data point is Debian LTS is supported > for 5 years [3]. > > Steven would like to see LTS be supported for 4 year full support + 1 > year security fix only [4]. I'm not sure how feasible this is with > current set of maintainers (in fact, only Jan and Ian at the > moment). But in the end there is nothing that prevents other people > from stepping up and taking over the tree. We saw that with Xen 3.4 > already. Could we just keep the same general scheme of "maintain 3 releases"? If the most recent release was *not* an LTS, we'd have one release + 2 LTSes. If the most recent release *was* an LTS, we'd have 3 LTSes -- the last one supported until a non-LTS release came out. If LTSes happen every 4 releases, then we'd get an LTS release every 2 years, giving is 4.5 years support (54 months). -George