Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: <8738oc5b31.fsf@v35516.1blu.de>
References: 
 <CALznzY7FDoRUnAd-MyrDBfddKqymQaCwPiyZBvfEApn-XMFFqg@mail.gmail.com>
	<ADD8565E-1C42-45A8-9163-F9E12C9D4CA5@gmail.com>
	<CALznzY5tnaRjN9q87Xrxj4hqWSmsSAnEx1J=CJoKQQRHTz4kgQ@mail.gmail.com>
	<CAB917R+tWS8BdteWOa-d9bpm1mBV2HE8WrfAu1MgyhcKKHCzmA@mail.gmail.com>
	<5253C871.2050307@apache.org>
	<8738oc5b31.fsf@v35516.1blu.de>
Date: Tue, 8 Oct 2013 12:40:30 +0200
Message-ID: 
 <CAEQx=x=Jgf1PAFuWzOvXZBHTdnktXFd1cZ+6qw0U1h72MPUfAA@mail.gmail.com>
Subject: Re: [DISCUSS] API compatibility policy
From: Torsten Curdt <tcurdt@vafer.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=089e01176b43cd61b404e83865f8

--089e01176b43cd61b404e83865f8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 the
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 <bodewig@apache.org> wrote:

> On 2013-10-08, Emmanuel Bourg wrote:
>
> > Le 07/10/2013 20:14, Benedikt Ritter a =C3=A9crit :
>
> >> - 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 risk
> of breaking everything" lately.  I really value the stability commons
> 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
>
>

--089e01176b43cd61b404e83865f8--