On Thu, Jul 1, 2010 at 2:13 AM, sebb <seb...@gmail.com> wrote: > On 1 July 2010 03:23, Henri Yandell <flame...@gmail.com> wrote: >> On Wed, Jun 30, 2010 at 1:38 PM, sebb <seb...@gmail.com> wrote: >>> On 30/06/2010, Henri Yandell <flame...@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.
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. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
