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
