From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id CD074374C for ; Tue, 15 Dec 2015 20:15:31 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 5E0DB8CF55; Tue, 15 Dec 2015 19:15:30 +0000 (UTC) Received: from dhcp-41-137.bos.redhat.com (ovpn-113-146.phx2.redhat.com [10.3.113.146]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBFJFScX016787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Dec 2015 14:15:29 -0500 To: "O'Driscoll, Tim" , Thomas Monjalon , "dev@dpdk.org" References: <1667533.heuKAiE6KB@xps13> <26FA93C7ED1EAA44AB77D62FBE1D27BA6747CE41@IRSMSX108.ger.corp.intel.com> From: Dave Neary Message-ID: <567066CF.2040404@redhat.com> Date: Tue, 15 Dec 2015 14:15:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA6747CE41@IRSMSX108.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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 19:15:32 -0000 Hi, You could just bump the major version for the first release of the new year - in this case, we would make 2.6 be 3.0. It achieves the same objective without having a big discontinuity in the release numbers. Thanks, Dave. On 12/15/2015 08:37 AM, O'Driscoll, Tim 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. > > > Tim > -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338