Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-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 A466010885 for ; Tue, 8 Oct 2013 12:53:36 +0000 (UTC) Received: (qmail 33087 invoked by uid 500); 8 Oct 2013 12:53:34 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 32834 invoked by uid 500); 8 Oct 2013 12:53:34 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 32822 invoked by uid 99); 8 Oct 2013 12:53:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Oct 2013 12:53:33 +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 (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.215.41] (HELO mail-la0-f41.google.com) (209.85.215.41) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Oct 2013 12:53:28 +0000 Received: by mail-la0-f41.google.com with SMTP id ec20so7000673lab.28 for ; Tue, 08 Oct 2013 05:53:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type:content-transfer-encoding; bh=RPt4PQ4SJ6d8RWaLeh2uhAG7ECqUvF+8dOPZmzx7YLQ=; b=lM0ezpBgNb5m9X4DAencDB0yHmYtAPeNsD9s6YZLlfjuJjdCwerMM5utXlAOP1MU5v br/vcaDB3g0A0quwP4y+/UaFWf0bRGbHyEAd6mK0nDoZ1S9C1UQTrqjOSpXhz7siFvO8 TlXlMjQpGMHMIKpov+QodiqA/ktoB+KNrYiAIGMeWeyrR5aueBFZy456f662cvIZJ9Ng LCa/ZkWHyp80+u8noAzIXxD5HhUsff+hji1WIa1g+xnsIJVjjJbLKfhfvbapnarcD1Nq ezWKeHMjE24FP+rse91jeeKUPKJZRS+Htw2GOhLRcungFjywblm5E0GKzW2ZgluS2dx5 EAlw== X-Gm-Message-State: ALoCoQmGpPULufn1r6emLqhDUHY6dJv5qdN8pj5SPitRwrn5Lsi1ZOALRKYjugPnp1+nOsoWmqV8 X-Received: by 10.112.200.100 with SMTP id jr4mr1606101lbc.36.1381236787295; Tue, 08 Oct 2013 05:53:07 -0700 (PDT) MIME-Version: 1.0 Sender: jcarman@carmanconsulting.com Received: by 10.112.161.230 with HTTP; Tue, 8 Oct 2013 05:52:47 -0700 (PDT) In-Reply-To: References: <5253C871.2050307@apache.org> <8738oc5b31.fsf@v35516.1blu.de> <9072772364892188026@unknownmsgid> From: James Carman Date: Tue, 8 Oct 2013 08:52:47 -0400 X-Google-Sender-Auth: KB7Bx5XE4j6Zt08Rc-CHzOap-ug Message-ID: Subject: Re: [DISCUSS] API compatibility policy To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org However, code modifications can be vetoed and nobody can overrule the veto. On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory wrote= : > On Tue, Oct 8, 2013 at 8:38 AM, James Carman = wrote: > >> Yes, we know we're allowed to do that, but folks seem to fight against >> moving forward. >> > > All you need is a [VOTE] and be done with it. > > Gary > > >> >> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory >> wrote: >> > You can break BC all you want when you do it in a NEW package. For >> > example lang3. >> > >> > Gary >> > >> > On Oct 8, 2013, at 6:41, Torsten Curdt wrote: >> > >> >> Cannot remember which component from the top of my head - but it was >> >> related to package name changes. >> >> >> >> My style of thinking: x.y.z >> >> >> >> x - no compatibility >> >> y - source compatibility >> >> z - binary compatibility >> >> >> >> is simple and makes sense. >> >> >> >> It's OK to put some burden on the users when upgrading - as long as t= he >> >> expectations are set correctly. >> >> But I am pretty sure we discussed that before and some people did not >> agree. >> >> >> >> cheers, >> >> Torsten >> >> >> >> >> >> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig >> wrote: >> >> >> >>> On 2013-10-08, Emmanuel Bourg wrote: >> >>> >> >>>> Le 07/10/2013 20:14, Benedikt Ritter a =E9crit : >> >>> >> >>>>> - loosen API compatibility policy? >> >>> >> >>>> This topic alone deserves its own thread I think. >> >>> >> >>>> Ensuring binary/source compatibility is very important. >> >>> >> >>> +1 >> >>> >> >>> I guess I've done too much ruby with "every bundle update runs the r= isk >> >>> of breaking everything" lately. I really value the stability common= s >> >>> provides. >> >>> >> >>> That being said, I'm sure there are cases where our policy seems >> >>> stricter than it needs to be - even though I haven't seen a really >> >>> difficult case in the one component I contribute to. >> >>> >> >>> Stefan >> >>> >> >>> --------------------------------------------------------------------= - >> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> >>> For additional commands, e-mail: dev-help@commons.apache.org >> >>> >> >>> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> > For additional commands, e-mail: dev-help@commons.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org >> >> > > > -- > E-Mail: garydgregory@gmail.com | ggregory@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org