Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [BCEL] next compatible release version number - 5.3 or 6.0?
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: <CACmp6kri72=_NPzkQe2Gpi1tQ+mrBxzu5dmJPspT1hn+8w5XZQ@mail.gmail.com>
Date: Tue, 7 Jun 2016 11:56:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <20F3932B-1A08-4D6A-84DA-0CEC5E822983@dslextreme.com>
References: <CAOGo0VaTDqV+j5vOVtK_8fhUh50KYBW7sus1vYhTJWFUTG894A@mail.gmail.com> <2447769.KL3uinzuLV@pinguin> <CAOGo0VYTNupjas3xX8xBWveUsBB6kMs+X6M4Ns92Cw1Pbyg3bw@mail.gmail.com> <5272424.PUgU6YUzV8@pinguin> <77E6B6D0-A0BC-4964-A3A9-2D3E81111C61@dslextreme.com> <CACmp6kri72=_NPzkQe2Gpi1tQ+mrBxzu5dmJPspT1hn+8w5XZQ@mail.gmail.com>
To: Commons Developers List <dev@commons.apache.org>
archived-at: Tue, 07 Jun 2016 18:56:20 -0000

I have no problem with changing the artifactId to Foo2 and the packages =
to match and then starting at 1.0. I=E2=80=99d also be OK with =
increasing the version number. If the API really is incompatible IMO =
changing the artifactId is the best indicator of that.

Ralph

> On Jun 7, 2016, at 11:47 AM, Matt Sicker <boards@gmail.com> wrote:
>=20
> What version number would you use to indicate that the API barely =
matches
> anymore then? Different group or artifact IDs?
>=20
> On 7 June 2016 at 12:12, Ralph Goers <ralph.goers@dslextreme.com> =
wrote:
>=20
>> Actually, a 6.0 release with the same coordinates would imply that =
there
>> are behavioral changes but the API is sufficiently compatible that =
you
>> won=E2=80=99t get things like NoSuchMethodError.
>>=20
>> Ralph
>>=20
>>> On Jun 7, 2016, at 9:33 AM, Andrey Loskutov <loskutov@gmx.de> wrote:
>>>=20
>>> On Tuesday 07 June 2016 17:26 sebb wrote:
>>>> On 7 June 2016 at 17:18, Andrey Loskutov <loskutov@gmx.de> wrote:
>>>>> On Tuesday 07 June 2016 17:15 sebb wrote:
>>>>>> There have been quite a lot of changes to BCEL since 5.2.
>>>>>>=20
>>>>>> Lots of places currently mention 6.0 (@since; JIRA; probably
>> elsewhere).
>>>>>>=20
>>>>>> So whilst 5.3 might be OK as the next release version, it's going =
to
>>>>>> be a lot of work to change all the references.
>>>>>>=20
>>>>>> I therefore propose we should use 6.0 for the backwards =
compatible
>>>>>> release using the original Java package names and Maven =
coordinates.
>>>>>>=20
>>>>>> A subsequent incompatible release can always use 7.0.
>>>>>=20
>>>>> +1 for 6.0.
>>>>> Even if BCEL trunk code after some backwards compatible changes =
will
>> don't break the BC, it most likely will break the behavior.
>>>>=20
>>>> Hopefully not, otherwise it negates most of the reasons for =
providing
>>>> a compatible release.
>>>>=20
>>>> It may be acceptable to break behaviour in such a way that only a =
few
>>>> unusual use cases are broken, but if every downstream user has to
>>>> recode their app then there's no point in striving for BC.
>>>>=20
>>>> AIUI the whole point of the exercise is to provide a drop-in =
release.
>>>=20
>>> As I saw in FindBugs after experimental port to BCEL6 (
>> https://issues.apache.org/jira/browse/BCEL-273), one still need to =
care
>> about behavior changes - it is a major release.
>>> And this is acceptable for me as a user of that API, because I know =
that
>> nothing is for free.
>>> But the hope is that this can be handled with much smaller effort =
and
>> without affecting / breaking other 3rd party libraries.
>>> So in  best case this is a drop-in, in *worst* case one need to fix =
some
>> smaller issue here and there, but it is definitely not a nightmare of
>> changing *everything*, entire software stack, just to be able to run =
on
>> Java 7/8.
>>>=20
>>> --
>>> Kind regards,
>>> google.com/+AndreyLoskutov
>>>=20
>>> =
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>=20
>>>=20
>>=20
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>=20
>>=20
>=20
>=20
> --=20
> Matt Sicker <boards@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org