commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@blueyonder.co.uk>
Subject Re: [beanutils] Summary of propsed/committed changes for Bugs
Date Mon, 12 Jul 2004 23:56:53 GMT
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" <robertburrelldonkin@blueyonder.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message