commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [lang] 3.0-beta? [Was: When is next release of commons-lang planned?]
Date Thu, 01 Jul 2010 16:00:12 GMT
On 1 July 2010 16:29, Henri Yandell <> wrote:
> 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
>>>>>  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 :)

I've already done the package files; decided it was quicker!

>>>> 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.
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message