From dev-return-24096-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Nov 13 19:43:40 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CA550D6A6 for ; Tue, 13 Nov 2012 19:43:40 +0000 (UTC) Received: (qmail 21150 invoked by uid 500); 13 Nov 2012 19:43:40 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 21116 invoked by uid 500); 13 Nov 2012 19:43:40 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 21108 invoked by uid 99); 13 Nov 2012 19:43:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Nov 2012 19:43:40 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-ia0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Nov 2012 19:43:33 +0000 Received: by mail-ia0-f180.google.com with SMTP id f6so5344586iag.11 for ; Tue, 13 Nov 2012 11:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=9dk8JVMBCDrXmh/gMgLFdpBdnOmbodEA0/ncjvmIGFA=; b=bQgczTnXU7U/HI0tII4tEL+LEKjTmYP4dzT+dlfnL2DaPvy2fS0zIivHyZMJCFs8Qj PqN1+hm+sWkGw5P/bHK/ET/5jkZSsnxynXnFq7sjEdBbyDIWDHloveTTCIm8DN9XS8x1 67l4nYtiyCHOTsqQJAyR6u0k2NTxrhox/H1KS8wdmK2Ektq+1/YtfwSrL7KAxz52gDcw GtYwA/tPRPWj+FIMtop/Rmka0F/bPHoNA1DMmLOXg897199LdPAp/5X0dt5auxAQ5rje Sd2IFnB0gAIxdcw1bwwcwQPNdUrzRRrhtibbQj6e/MosvqQ9shrFbdsbcqeyBS1dRDLU AdDw== MIME-Version: 1.0 Received: by 10.50.100.229 with SMTP id fb5mr12094557igb.11.1352835793360; Tue, 13 Nov 2012 11:43:13 -0800 (PST) Received: by 10.64.77.196 with HTTP; Tue, 13 Nov 2012 11:43:13 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Nov 2012 20:43:13 +0100 Message-ID: Subject: =?windows-1252?Q?Re=3A_Let=92s_ship_1=2E3=2E0_now=2E?= From: Benoit Chesneau To: "dev@couchdb.apache.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Why 60 days. Why not "when it"s ready" and by it's I mean doc & cors. if it's part of 1.3 . - benoit On Tue, Nov 13, 2012 at 8:28 PM, Jan Lehnardt wrote: > Hey all, > > when we set out to ship 1.3.0, we thought the cors and docs > branches were just around the corner. That was a couple of > weeks ago. We are just starting with this, but the whole > idea of time-based releases is that we do not wait for > feature branches to be ready. > > I=92d like to propose that we ignore everything we=92ve said > before and do the following: > > - ship 1.3.0 as reflected in the 1.3.x branch now. > - merge docs and cors to master whenever they are ready. > - branch 1.4.x 60 days from now. > - ship 1.4.0 90 days from now. > > (by =93ship=94 I mean =93start the usual release procedure=94) > > > Why call it 1.3.0 and not 1.2.1? > > Excellent question. Quoting NEWS: > >> * The source code repository was migrated from SVN to Git. >> * Added view request duration to Futon. >> * Speedup in the communication with external view servers. >> * Fixed unnecessary conflict when deleting and creating a >> document in the same batch. >> * New and updated passwords are hashed using PBKDF2. >> * Fix various bugs in the URL rewriter when recursion is involved. >> * Added Server-Sent Events protocol to db changes API. >> * Moved the JS test suite to the CLI >> * Make password hashing synchronous when using the /_config/admins API. >> * Added utc_id UUID algorithm. >> * encode database name during URL rewriting. >> * Include user name in show/list ETags. > > A bunch of new minor features (PBKDF2, utc_id UUIDs, > Event Source _changes) and infrastructure changes > (Git move, CLI tests) all make me think this is a > 1.3.0, not a bugfix release like 1.2.1 would be. > > But, 1.3.0 won=92t have any flagship features! Yup, > from now on we=92ll ship many more of these minor > releases, we start getting used to it :) > > What do you think? > > Cheers > Jan > -- > >