commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] 3.0-beta? [Was: When is next release of commons-lang planned?]
Date Thu, 01 Jul 2010 15:29:57 GMT
On Thu, Jul 1, 2010 at 2:13 AM, sebb <> wrote:
> On 1 July 2010 03:23, Henri Yandell <> wrote:
>> On Wed, Jun 30, 2010 at 1:38 PM, sebb <> wrote:
>>> On 30/06/2010, Henri Yandell <> wrote:
>>>> Here are example tarballs, jar and a site for a 3.0 beta:
>>> Is this basically the same code as in commons-lang-trunk?
>> Yes - exactly the same.
>>>>  The site isn't intended to be ready - that can be done later. What it
>>>>  does right now is provide the relevant 3.0 reports.
>>>>  What I'd like to know right now is if it looks good and whether I
>>>>  should go ahead and tag 3.0-beta and do a real release build. I think
>>>>  we're ready to build a beta. I don't expect a lot of API change after
>>>>  this, and I don't know of any bugs in 3.0 that weren't in 2.x.
>>>>  So not a release vote, but looking for consensus from anyone (users,
>>>>  committers, pmc) that it's time to put a beta stake in the ground.
>>> In general I agree.
>>> However, I think it is essential to document the intended class thread-safety.
>>> For example, the mutable package is not intended to be thread-safe
>>> whereas concurrent is presumably intended to be.
>> If you want to do that, then I can see delaying for a defined time. If
>> it's just something you think someone else should do, I know it isn't
>> my priority and not something I'd see as a release blocker for either
>> a beta or for 3.0 itself.
> I'm happy to start adding comments to the classes and/or package.html files.

Go for it :)

>>> The package.html files also need some work.
>> They're pretty tiny, so shouldn't be much [unless you have visions of
>> writing a lot in there].
> Actually, when looked at in context, they are sufficient.
> Though it might be worth adding some details on thread safety to them.

I think the class files are probably sufficient - having better
package.htmls would then be a separate task and would presumably
include covering thread safety.

> ==
> Given that we have changed all the package names, the Clirr report is
> fairly useless.
> Is it possible to use it to compare corresponding classes?
> E.g. maybe use Shade to create a lang3 version of lang2 or vice-versa?
> Or maybe Clirr has an option to alias classes?

Or simpler; a mv of the lang3 directory to lang then running of the
clirr report. I've had that setup and running, I just need to put a
computer back where it used to be post some home improvement and get
it pushing the page up to people.apache.


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

View raw message