commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: [BCEL] next compatible release version number - 5.3 or 6.0?
Date Tue, 07 Jun 2016 18:47:04 GMT
What version number would you use to indicate that the API barely matches
anymore then? Different group or artifact IDs?

On 7 June 2016 at 12:12, Ralph Goers <ralph.goers@dslextreme.com> wrote:

> 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’t get things like NoSuchMethodError.
>
> Ralph
>
> > On Jun 7, 2016, at 9:33 AM, Andrey Loskutov <loskutov@gmx.de> wrote:
> >
> > 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.
> >>>>
> >>>> Lots of places currently mention 6.0 (@since; JIRA; probably
> elsewhere).
> >>>>
> >>>> 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.
> >>>>
> >>>> I therefore propose we should use 6.0 for the backwards compatible
> >>>> release using the original Java package names and Maven coordinates.
> >>>>
> >>>> A subsequent incompatible release can always use 7.0.
> >>>
> >>> +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.
> >>
> >> Hopefully not, otherwise it negates most of the reasons for providing
> >> a compatible release.
> >>
> >> 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.
> >>
> >> AIUI the whole point of the exercise is to provide a drop-in release.
> >
> > 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.
> >
> > --
> > Kind regards,
> > google.com/+AndreyLoskutov
> >
> > ---------------------------------------------------------------------
> > 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
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message