Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-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 5E953C335 for ; Thu, 4 Dec 2014 12:42:16 +0000 (UTC) Received: (qmail 2050 invoked by uid 500); 4 Dec 2014 12:42:11 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 2022 invoked by uid 500); 4 Dec 2014 12:42:10 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 82471 invoked by uid 99); 3 Dec 2014 20:42:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Dec 2014 20:42:10 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=LOTS_OF_MONEY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of david.medinets@gmail.com designates 74.125.82.42 as permitted sender) Received: from [74.125.82.42] (HELO mail-wg0-f42.google.com) (74.125.82.42) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Dec 2014 20:42:06 +0000 Received: by mail-wg0-f42.google.com with SMTP id z12so20934117wgg.1 for ; Wed, 03 Dec 2014 12:41:45 -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; bh=ksU76mbMvYdc6JOHBwOEbuG/5SC30X50Av0IK2W4WLE=; b=i0SSBHJaLsaRQBlwZjt2KWAgOVtYKHjeD5ERhM50favZUl47JU7/uHlGUghsi6TWxt /MKgf/FcyIuXVN6L2B1UBwLqMZyqo2NWzmkp0jI7mF6GJphoe41vCnYtmbW3geBkuzSL OiV1NQ8OTXbs/yNIgwvUGOMcN/gBBcnlkTCAptibTxC7oZPd6jWaF3yi85Tva8NzjTcp MMRBJe4OeUba+pYATsRbpQmpZ+fWXn14KAk1cGNYEadhDDaqraMTIb+qRk+6aDPPf8lP 4oo8MEMfkg2a/OFr64i7seZyPMXGIsvWW6KTZH9zh9bfoZzw7fXJ8rQ1gRHXT3OKBJ/m ghXQ== MIME-Version: 1.0 X-Received: by 10.194.52.36 with SMTP id q4mr10613570wjo.114.1417639305221; Wed, 03 Dec 2014 12:41:45 -0800 (PST) Received: by 10.194.13.65 with HTTP; Wed, 3 Dec 2014 12:41:45 -0800 (PST) In-Reply-To: References: Date: Wed, 3 Dec 2014 15:41:45 -0500 Message-ID: Subject: Re: [VOTE] API release policy for 1.7/2.0 From: David Medinets To: accumulo-dev Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Dec 3, 2014 at 9:48 AM, Sean Busbey wrote: > API additions matter here because when a system integrator makes an > application on top of Accumulo they often start at the latest version they > can find. Later, they may have a client with a regulatory requirement to > use an earlier version. Porting backwards is just as hard as porting > forwards in our code base. With this logic, code bases would never evolve. I want a dynamically evolving tool that reacts as quickly as possible to better ideas. Waiting six months for a release that might be delayed does not make sense to me; especially for an API addition. I do not want to deeply consider the needs of system integrators when thinking about evolution of the code case and feature set. When would that conversation stop? Should we include Lumify or GeoWave in our conversations? What about the Accumulo port of Presto? Should we place some limit on system integrator size - only paying attention when the integrator is donating resources to the project? Or perhaps if the integrator has only three clients they are not big enough? What if Optum or Bloomberg has $50 million invested in using Accumulo. They aren't an integrator but a direct user. Are their needs less important? Is there some limit to say which customer is important enough to halt a feature set?