Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of teofili@adobe.com designates
 64.18.1.208 as permitted sender)
From: Tommaso Teofili <teofili@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Fri, 10 May 2013 09:41:59 +0100
Subject: Re: svn commit: r1480921 -
 /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java
Thread-Topic: svn commit: r1480921 -
 /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/DataIdentifier.java
Thread-Index: Ac5NWjzoaU5X5msTQiCnXezaRejB3w==
Message-ID: <771F90AA-A2E7-4A09-B1CB-A4CBBF62F802@adobe.com>
References: <20130510081446.101DD238889B@eris.apache.org>
 <CAOFYJNacF34LzHPwPSGBvK7MEGx7J_7_+6TRJngfFz96U8ZD8w@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNacF34LzHPwPSGBvK7MEGx7J_7_+6TRJngfFz96U8ZD8w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 10/mag/2013, at 10:28, Jukka Zitting wrote:

> Hi,
>=20
> On Fri, May 10, 2013 at 11:14 AM,  <tommaso@apache.org> wrote:
>> JCR-3534 - avoiding backward compatibility issue by adding back construc=
tor DataIdentifier(byte[])
>=20
> DataIdentifier is an internal class so there's only a very limited
> backwards compatibility issue to consider.
>=20
> We've generally only promised strict binary compatibility for external
> implementations of extension points like the DataStore or
> PersistenceManager interfaces within a stable maintenance branch. For
> example upgrading from 2.6.0 to 2.6.1 should not require changes in
> such components. However, across minor versions or unstable releases,
> like from 2.4.x to 2.6.y or from 2.7.x to 2.7.y, we can expect such
> implementations to be updated to match any relevant changes in
> Jackrabbit internals.

agree, thanks for pointing out.

>=20
> In this case for example any DataStore implementations will in any
> case need to be adapted to implement the new
> getIdentifierFromReference() method (even if that implementation
> always returns null), so the value of keeping DataIdentifier intact
> isn't too high.

i see, you're right that isn't too important for compatibility issues; also=
 I thought it'd have made sense to keep having it.

Thanks,
Tommaso

>=20
> BR,
>=20
> Jukka Zitting