commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
Subject Re: [lang] Preparing for a 2.5 release
Date Mon, 08 Feb 2010 18:19:35 GMT
On Sun, Feb 7, 2010 at 3:07 AM, Henri Yandell <> wrote:
> On Sat, Feb 6, 2010 at 12:40 PM, Niall Pemberton
> <> wrote:
>> On Fri, Feb 5, 2010 at 4:20 AM, Henri Yandell <> wrote:
>>> My general thinking is:
>>> "+1, thanks for doing this"
>>> mixed with:
>>> "We now have two versions in development at the same time, we can no
>>> longer just charge along coding - we need process"
>>> Namely, do we put anything in 2.5 as long as it doesn't affect
>>> backwards compat, do we keep adding enhancements, do we only do
>>> bugfixes (or critical bugfixes)?
>> ATM its just backporting compatible trunk changes. So were not adding
>> things to the branch that aren't in the trunk. IMO what gets
>> backported should be down to those willing to do the work. Why would
>> you want to dictate what someone can or can't do?
> Trying to avoid two divergent products and the user confusion. It's
> 2.5 instead of 2.4.1, we're adding new features from 3.0 rather than
> just focusing on bugfixes so now we have two Commons Langs.
> Should I be making a JDK 1.3 version of
> Should we add 'JDK 6' features implemented for JDK 1.3?
> Basically trying to make sure we don't end up with CLI1 and CLI2 :)

If someone wants to do something different in the 2.x branch from
trunk, then I think it needs to be discussed first. But if its just
backporting features from trunk then we don't have this issue.

>>> It starts to feel that we need to emulate Tomcat's methodology more of
>>> working in trunk then voting particular patches back into the legacy
>>> version.
>> I'm -1 to this. Tomcat's methodology arose out of the acrimony within
>> their PMC. That situation doesn't exist here so I don't see why we
>> would want to make this unnecessarily beaurocratic.
> Regardless of origin, I've liked watching it from a bugfix branch
> point of view.

Watching is one thing. Having to operate an additional beaurocratic
process needs good reason IMO. I doubt the Tomcat people really wanted
to operate that way - but it was better than the acrimony that
preceeded it.


> Hen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message