commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject [VOTE][RESULT] Release Apache Commons Functor 1.0 based on RC1
Date Sun, 23 Oct 2011 11:46:49 GMT
Hi all guys,
Since 72 hours passed I'm declaring this vote as closed and NOT passed
with only 2 positive votes from PMCs:

 * Matt Benson
 * Simone Tripodi (implicit)

no other votes were cast.

We will continue working towards a new RC to submit.

Thanks to all for your support and patience!
Have a nice weekend, all the best!
Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Oct 21, 2011 at 6:36 PM, sebb <sebbaz@gmail.com> wrote:
> On 21 October 2011 16:04, Matt Benson <gudnabrsam@gmail.com> wrote:
>> On Fri, Oct 21, 2011 at 5:27 AM, sebb <sebbaz@gmail.com> wrote:
>>> On 21 October 2011 11:03, Emmanuel Bourg <ebourg@apache.org> wrote:
>>>> Le 21/10/2011 11:10, Simone Tripodi a écrit :
>>>>
>>>>> So, as you proposed, would be reasonable to drop the 1.0 and decide
>>>>> upon for a 0.1 as current release?
>>>>
>>>> Yes, or a 1.0-beta with clear indications that this is a preview intended
to
>>>> gather user feedback.
>>>
>>> I don't think it's ready for beta status yet.
>>>
>>> But - is there any pressing need to make a release?
>>
>> The most immediate thing is that [proxy] 2 needs a unary predicate.
>> It becomes ridiculous for every component we have to define such a
>> basic interface in a different way.  So [proxy] 2 can never be
>> released without a [functor] release, etc.
>>
>>>
>>> For developer testing, a snapshot release is probably sufficient, and
>>> can be updated very quickly - no need for a vote.
>>
>> This is indeed sufficient for the immediate future, but again, becomes
>> *insufficient* soon enough.  I don't personally see what purpose is
>> served by a 0.x release, but I have to say it's frustrating to work on
>> a component and only when a release is proposed does everyone who
>> couldn't have cared less before come out of the woodwork to suddenly
>> find design issues (issues such as undocumented @SuppressWarnings come
>> down to personal opinion and I would personally argue they shouldn't
>> be release blockers, particularly as more often than not the
>> justification is obvious).
>
> That entirely depends on circumstances; I've seen lots of cases where
> they are just used to silence warnings, with no attempt to solve the
> cause of the warning.
> In some (perhaps rare) cases, fixing the warning may point to a
> fundamental design issue, and/or need to change the API.
>
>> For those of you who have suddenly decided
>> you care about this component:  if we discuss and resolve the
>> fundamental design concerns (i.e. no promises beyond reaching
>> consensus), can you stay engaged long enough for us to get this
>> wrapped up?
>
> I'm happy to contribute if I can; I had not realised that an RC was
> imminent otherwise I might well have dived in earlier.
>
> There are too many components to follow every single one all the time;
> besides, things are often in a state of flux between releases -
> there's no point dotting i's and crossing t's if the entire paragraph
> is about to be rewritten. Been there, done that in other projects.
>
>> Matt
>>
>>>
>>>>
>>>> Emmanuel Bourg
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>

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


Mime
View raw message