commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [lang] Doing the release
Date Wed, 27 Aug 2003 19:21:09 GMT
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" <mhawthorne@alumni.pitt.edu>
>> 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" <bayard@generationjava.com>
>>>
>>>
>>>> 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:noel@devtech.com]
>>>>>> 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: commons-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


Mime
View raw message