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.go...@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 <losku...@gmx.de> wrote: > > > > On Tuesday 07 June 2016 17:26 sebb wrote: > >> On 7 June 2016 at 17:18, Andrey Loskutov <losku...@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-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
