From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) by dpdk.org (Postfix) with ESMTP id E8284E72 for ; Tue, 15 Dec 2015 16:39:06 +0100 (CET) Received: by mail-vk0-f51.google.com with SMTP id j66so7836107vkg.1 for ; Tue, 15 Dec 2015 07:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infiniteio-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3w7JXKl5tIUnXLL+LQt3Aq80pG09XYvChaTF5tFs+tM=; b=F4W6uNSEhZrTL5DLvjkBxG2/rvjI6gPhrsYrvTAX4ND1iLcljGgykcTEAHgCDKxoSC cjQ0ou2diER1FIgc3P1wlczAYApmHwgIKeq8GxL0IT9C5o9IKRa+2vTzAb7/XoH9YWPa vAHyPCwjcIvT0O6TEPiHI3DC8pwWgbijRfmELr53RutO9nawnspSRrwOnALxAjf7yvpq 2IKqNA/ee4Qz4CPD6YZd6MizG9tNWmYH1TPx7J6nSPDfsOWVvIQxYBg8nu4rxOYy+XOu evGlukJ2W0+GuKxRHE9KGMNrYX6kmiWhqyyzK9CPjhGiJ6idjkoLFAOuhC9VvOXu0iNk vobg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3w7JXKl5tIUnXLL+LQt3Aq80pG09XYvChaTF5tFs+tM=; b=ZXVKN6sqUsAvZpy9cOx35WverWSvZ1mLxDwnli9PswDPeEKp3J9o6grZ7BxWr6iHnD 6HDHS4+xrn6DJ9VRWV/8BhNLzFhtq4GrijGBgwI1Q9MjFzUY4sf5c/IKEDJi7NVbfbA2 kVqR0KITxWm46OorfCsFtDZ6UDNjnyv69tIWZyOYmhf7WCeYqEnUa+DesOAW1O72O3aJ UnRdH9nFXMSuxVzak9jEW/Enrm82R9F+4veHAB4zqRWSqxu/WeqQ9rBo5t1yDbMarDWQ GH5Gusa/OfqE0Qqnc7JiZ+QcXjQT0dRFAJqjaVtA/wWDBwCYfU24FcZNDus3AOSZnUSq WvsQ== X-Gm-Message-State: ALoCoQmxyZyZespE9unwoyuZ2snPDDt7R6i+rpO4+FewM6/9G+aPFNvGt3y1y0Td/5bRAaoo5ldZ0/2Ug7pBg1zY5MBxmbxBXg== MIME-Version: 1.0 X-Received: by 10.31.52.68 with SMTP id b65mr29459918vka.150.1450193946444; Tue, 15 Dec 2015 07:39:06 -0800 (PST) Received: by 10.103.78.193 with HTTP; Tue, 15 Dec 2015 07:39:06 -0800 (PST) In-Reply-To: <492F5A44-351F-4A3B-86FE-BFEEBC14AFC5@intel.com> References: <1667533.heuKAiE6KB@xps13> <26FA93C7ED1EAA44AB77D62FBE1D27BA6747CE41@IRSMSX108.ger.corp.intel.com> <492F5A44-351F-4A3B-86FE-BFEEBC14AFC5@intel.com> Date: Tue, 15 Dec 2015 09:39:06 -0600 Message-ID: From: Jay Rolette To: "Wiles, Keith" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] releases scheduling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 15:39:07 -0000 +100 for the LTS One of the bigger challenges for products using DPDK is that there is so much change going in each release with very limited testing. Trying to even remotely keep up is too risky. We end up back-porting various fixes and enhancements to whatever version we are on (1.6rc2 currently). Jay On Tue, Dec 15, 2015 at 8:42 AM, Wiles, Keith wrote: > On 12/15/15, 7:37 AM, "dev on behalf of O'Driscoll, Tim" < > dev-bounces@dpdk.org on behalf of tim.odriscoll@intel.com> wrote: > > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > >> Sent: Sunday, December 13, 2015 7:23 PM > >> To: dev@dpdk.org > >> Subject: [dpdk-dev] releases scheduling > >> > >> Hi all, > >> > >> We need to define the deadlines for the next releases. > >> During 2015, we were doing a release every 4 months. > >> If we keep the same pace, the next releases would be: > >> 2.3: end of March > >> 2.4: end of July > >> 2.5: end of November > >> > >> However, things move fast and it may be a bit long to wait 4 months for > >> a feature. That's why I suggest to progressively shorten release terms: > >> 2.3: end of March > >> 2.4: mid July > >> 2.5: end of October > >> and continue with a release every 3 months: > >> 2.6: end of January > >> 2.7: end of April > >> 2.8: end of July > >> This planning would preserve some of the major holiday periods > >> (February, May, August, December). > >> > >> The first period, for the first submission of a feature, was 2 months > >> long. > >> Then we had 2 other months to discuss, merge and fix. > >> We should shorten only the first period. > >> > >> Anyway, the next deadlines should be unchanged: > >> - January 31: end of first submission phase > >> - March 31: release 2.3 > >> > >> Opinions are welcome. > > > >I think moving to quarterly releases is a good idea. Your proposal to do > this in a gradual way, so that we don't change the 2.3 dates, also makes > sense. > > > >Should we consider changing the release numbering at the same time? It's > difficult to keep track of when each 2.x release is due, and we don't have > any criteria in place for moving to 3.x in future. Many people like the > Ubuntu numbering scheme of Year.Month. Should we consider adopting that > convention? If we move in future to a model where we have long-term support > releases (something that was touched on in Dublin), then we could append an > LTS designation to the release number. > > +1 for the Ubuntu number and the LTS > > > > > >Tim > > > > > Regards, > Keith > > > > >