Robert, No problem - its a good learning experience for me being new to this committership. I'd rather just work on one version at a time, so don't create a branch unless you have other reasons to. I'm happy to revisit anything that doesn't make this cut for a later version. I'll wait for your feedback on the other stuff I did.
Niall ----- Original Message ----- From: "robert burrell donkin" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Monday, July 12, 2004 9:55 PM Subject: Re: [beanutils] Summary of propsed/committed changes for Bugs > hi niall > > thanks again for the hard work. i'm starting now to go through the bugs > reports. > > On 12 Jul 2004, at 20:01, Niall Pemberton wrote: > > > Its not an issue I have a strong opinion on - all I'm interested in is > > helping resolve the outstanding beanutils bugs to move it nearer a > > release. > > the plan (as far as the release goes) is to produce 1.7.0 service > release to address the narrow issue of collections compatibility. it > will also (incidentally) also introduce the beanification classes (so > downstream projects - such as struts - can start thinking about how > they want to move and so we can gain some feedback about issues such as > configuration). > > originally when the plan was to do the usual bug fixes before the > release but when i looked started to review the list of bugs, the list > looked too long and too risky. however, beanutils has been neglected > over a long period so i'd really like to find the energy to address as > many as possible. > > > The question then is whats the best course of action in relation to > > these > > bugs? > > exactly what we're doing now :) > > it's crucial to think about the best courses of action and mull over > possible solutions. it's very possible that we'll end up assigning > different fixes to different releases. i'm as happy managing two > release branches as one (if that's what's the best approach). > > <snip> > > > I guess I'm for the pargmatic option - because I'm just think of the > > flood > > of emails/bugs with doing the whole thing, what do you think? > > working on deep library components such as beanutils is often hard and > unglamourous but you'll learn things working on these that you won't > learn elsewhere. for beanutils, backwards compatibility is of crucial > importance. it's important to apply narrow, focused fixes or to come up > with ways to provide flexibility that allows users to choose the > behaviour they want. > > for me, these bugs come under the general heading of bean query > language enhancements. the problem is that we're constrained by > backwards compatibility so there's a lot that we can't introduce at the > moment. the idea behind the beanification changes is to make it easier > to change stuff like the bean query language in both subtle and radical > ways. > > i'd be very unhappy about breaking backwards compatibility for this fix > but i do think that there's a definite user demand for an alternative > implementation along the lines Niall has indicated. personally, i'd > probably see such an implementation as an item for a 1.8.0 release. (i > don't see any reason why beanutils releases 1.7.0 and 1.7.1 shouldn't > happen relatively quickly.) if Niall fancies creating an alternative > implementation that supports maps, then i'd be happy creating and > managing a 1.7.1 release branch for the fixes. > > - robert > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
