commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [lang] 3.0-beta? [Was: When is next release of commons-lang planned?]
Date Thu, 01 Jul 2010 09:13:41 GMT
On 1 July 2010 03:23, Henri Yandell <flamefew@gmail.com> wrote:
> On Wed, Jun 30, 2010 at 1:38 PM, sebb <sebbaz@gmail.com> wrote:
>> On 30/06/2010, Henri Yandell <flamefew@gmail.com> wrote:
>>> Here are example tarballs, jar and a site for a 3.0 beta:
>>>
>>>  http://people.apache.org/~bayard/commons-lang-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.

>> 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.

==

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?

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

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


Mime
View raw message