Re: [lang] Doing the release

[robert burrell donkin]

i lost interest since it became clear that the original use i wanted to 
make of the code (in beanutils) wasn't going to happen.

i've now become interested in the possibility of using reflection for unit 
tests of (for example) gui components. it's common to want to code these 
fairly tightly. some of the code in there which (given the right security 
environment) gives the sort of clean clear interface that's needed for 
unit tests. so maybe i'll find some time to revisit [reflect].

- robert

On Wednesday, August 27, 2003, at 02:00 AM, Stephen Colebourne wrote:

[reflect] is intended to take the current stalled [lang.reflect] code and
make it a separate project. This would include reflection (with method
caching) and maybe C# style features.
Stephen

----- Original Message -----
From: "__matthewHawthorne" <[EMAIL PROTECTED]>
What's the status of the sandbox component [clazz]?   I believed this to
be a project including reflection utilities, but I might be mistaken.
Is this a different project than what you're suggesting in [reflect]?
As far as [io] is concerned, I'm hoping to submit a patch or two this
week, mostly focusing on improving the test coverage and simplifying the
api.  Since Jeremias is on vacation for 2 weeks or so, if any committers
would keep their ears to the ground and take a look at my patches I
would appreciate it.


Stephen Colebourne wrote:

Well, we want a release that works, so if that means waiting then thats
how
it goes. Don't want to miss the boat on any books or articles or other
stuff
though.

I'm marshalling [collections] hoping for a release soon. Perhaps if
[lang]
committers want something to do, the reflect code could be broken out
into a
sandbox [reflect]? Or the [lang] sandbox could be used. Or there could 
be
a
focus on [io].

I don't want to wait too long though, as [lang] feels like it might have
the
energy to get a 2.1 in a couple of months to fill in any 2.0 gaps. Also,
I
want to use [lang] at work!

Stephen

----- Original Message -----
From: "Henri Yandell" <[EMAIL PROTECTED]>

In addition to the question of us playing it a bit more by the rules,
the
Jakarta website is in a bit of a transition for a week or so. I'd 
rather
not do any deploys until the move from daedelus to minotaur is 
complete,
so am suggesting we back off until then. This sound doable?

Hen

On Sun, 24 Aug 2003, Gary Gregory wrote:



I'll take the blame for causing any confusion on this one since I had
committed these Javadoc changes "during" the vote, which was made 
more
difficult due to the extremely long email delays caused by the 
current


batch


of viruses going 'round.

My thought was that we were indeed voting on the build based on 
tagged
sources and that any new commits would be in a post >2.0 release 
(even
though, these changes being Javadoc changes are "harmless" and


beneficial to


the release IMHO ;-)

If we want to implement a code freeze in our environment on top of
using
tags, we could do that. I guess we'd have to vote on it too :-)

Gary



-----Original Message-----
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 24, 2003 00:00
To: Jakarta Commons Developers List
Subject: RE: [VOTE] Release of Commons Lang 2.0 [take 2]


Well, if there is a question about policy/process, why not just


freeze


the


code and restart the vote?


By tagging the CVS, he effectively has frozen the code for the


Release.  I


was simply curious about the policy because, as I said, other 
projects


are


stricter.  For example the HTTPd team has different rules
(http://httpd.apache.org/dev/release.html).
A Release Manager makes a release build, and it is automatically an


alpha.


It becomes a beta release when at least three Committers have voted


beta


status, and there are more +1 than -1.  It becomes a GA release when


at


least three Committers vote for GA (stable) status, and there are 
more


+1


than -1.  Notice that -1 is not a veto.  Notice, also, that the


package


itself may go through multiple status changes, but no packaging


changes.


The only allowable change is renaming the file to reflect the change


in


status; exceptions can be made if a change in the contents of the


tarball


(e.g., someone forgot to add the LICENSE file).  Otherwise, if a


change in


the CVS needs to be incorporated, it becomes a new release (with a 
new
vote).

Other projects, such as Avalon, also roll jars and then vote on them


as a


Release.  So I was just asking to understand what is established as


policy


here.  I wasn't challenging Henri's release.

--- Noel

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]