From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fNEOW-0002XK-Hl for qemu-devel@nongnu.org; Mon, 28 May 2018 05:24:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fNEOR-0001th-H0 for qemu-devel@nongnu.org; Mon, 28 May 2018 05:24:48 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:41092) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fNEOR-0001t6-AL for qemu-devel@nongnu.org; Mon, 28 May 2018 05:24:43 -0400 Received: by mail-wr0-f195.google.com with SMTP id u12-v6so19118025wrn.8 for ; Mon, 28 May 2018 02:24:43 -0700 (PDT) References: <20180430103312.GH3249@redhat.com> <20180430132107.0a37704d.cohuck@redhat.com> <20180502093326.2fbec55f.cohuck@redhat.com> <20180502075904.GF3308@redhat.com> <20180502091039.GK3308@redhat.com> From: Paolo Bonzini Message-ID: <17473814-91c4-6816-621c-1762473dc88e@redhat.com> Date: Mon, 28 May 2018 11:24:39 +0200 MIME-Version: 1.0 In-Reply-To: <20180502091039.GK3308@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "=?UTF-8?Q?Daniel_P._Berrang=c3=a9?=" , Liviu Ionescu Cc: Peter Maydell , Thomas Huth , Cornelia Huck , QEMU Developers , Stefan Hajnoczi On 02/05/2018 11:10, Daniel P. Berrangé wrote: >> it would allow to postpone incompatible removals to relatively seldom >> major releases, add new features during more often minor releases, and >> fix bugs during regular patch releases. >> >> major releases can be scheduled every 1-2 years, for example, minor >> releases every 3-6 months, and patch releases when needed. > No, we do not want to extend the deprecation period further just so that > we can adopt semver. We explicitly chose "2 releases", so that every > deprecation warning has the same lifetime - we don't want some deprecations > to be 4 months long, while other deprecation warnings are 1+1/2 years long. In practice it's already "at least" 2 releases, if only because sometimes 1) people forget, or 2) they are busy with more important things, or 3) we want to provide a good replacement and it turns out to be harder than 2 releases. Paolo