Since the old 2.0 branch is so... "sleepy" and I've not seen Simone here in a long time, I'd rather keep the train moving as it is and if someone really wants a breaking BC release, maybe that would be for a 3.0... or is this simple a case of changing BU APIs from returning [collections] concrete classes and/or interfaces instead of JRE interfaces?
Gary On Mon, Jan 1, 2018 at 8:12 AM, Benedikt Ritter <brit...@apache.org> wrote: > Hi, > > > Am 30.12.2017 um 16:24 schrieb Gary Gregory <garydgreg...@gmail.com>: > > > > Who can speak to that code base? > > I’ve worked on BeanUtils2 some years ago together with Simone Tripodi. I > think we should better work on this redesign instead oh pushing the old > code base as 2.0 just to fix some dependencies. In fact I think that > BeanUtils 1 exposes classes from Commons Collections in its public API is a > big mess that we should fix when we roll a new major release. > > Benedikt > > > > > Gary > > > > On Dec 30, 2017 03:54, "Benedikt Ritter" <brit...@apache.org> wrote: > > > >> > >> > >>> Am 29.12.2017 um 19:58 schrieb Gary Gregory <garydgreg...@gmail.com>: > >>> > >>> On Wed, Dec 27, 2017 at 11:55 AM, Gary Gregory <garydgreg...@gmail.com > > > >>> wrote: > >>> > >>>> The changes for: > >>>> > >>>> BEANUTILS-500 Upgrade commons-collections to 4 > >>>> > >>>> break BC (see BEANUTILS-500). > >>>> > >>>> Therefore, I created BEANUTILS-503: Change packaging from > >>>> org.apache.commons.beanutils to org.apache.commons.beanutils2 > >>>> > >>>> This change should happen sooner rather than later IMO to allow folks > >>>> using SNAPSHOT builds to adapt. > >>>> > >>>> Thoughts? > >>>> > >>> > >>> This is done is SVN trunk. > >> > >> We already have a complete rewrite of the BeanUtils API in the sandbox > >> [1]. What do we want to do with that? > >> > >> Regards, > >> Benedikt > >> > >> [1] http://svn.apache.org/viewvc/commons/sandbox/beanutils2/trunk/ > >> > >>> > >>> Gary > >>> > >>> > >>>> > >>>> Gary > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> 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 > >
