Gary,
In this case, we're dealing with a veto to a code modification, which
is allowed. Here's the information with respect to code modification
vetoes (http://www.apache.org/foundation/voting.html#Veto):
"A code-modification proposal may be stopped dead in its tracks by a
-1 vote by a qualified voter. This constitutes a veto, and it cannot
be overruled nor overridden by anyone. Vetos stand until and unless
withdrawn by their casters.
To prevent vetos from being used capriciously, they must be
accompanied by a technical justification showing why the change is bad
(opens a security exposure, negatively affects performance, etc. ). A
veto without a justification is invalid and has no weight."
Since there is a technical justification ("it's not necessary")
provided with this veto, it stands until "sebb" withdraws it.
That isn't to say that I agree with sebb's assessment, necessarily. I
think we should drop Java 5 like a bad habit. We already have a bad
reputation for living in the past. We need to be more
forward-leaning. We can always support older versions on older JDKs
if necessary (could be a YAGNI situation). If we do jump JDK
versions, I'd say we should jump major version numbers (which others
have disagreed with in the past). To me, version numbers are cheap
(look at Firefox!).
On Sat, Feb 25, 2012 at 9:32 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
> On Sat, Feb 25, 2012 at 9:19 AM, sebb <seb...@gmail.com> wrote:
>
>> On 25 February 2012 14:05, Gary Gregory <garydgreg...@gmail.com> wrote:
>> > Right now, in trunk, we have:
>> >
>> > Description Resource Path Location Type
>> > The method getInstance(Locale) is undefined for the type
>> > DateFormatSymbols FastDateParser.java
>> > /commons-lang/src/main/java/org/apache/commons/lang3/time line 352
>> > Java Problem
>> >
>> > Because we are using (still) some Java 6 code for this recent
>> contribution.
>>
>>
>> This one is trivial to fix:
>>
>> DateFormatSymbols symbols= new DateFormatSymbols(locale);
>>
>> > Let's stop this Java 5 craziness in trunk and update to Java 6.
>> >
>> > Ready, set, ... go?
>>
>> -1
>>
>> Completely unnecessary in this case.
>>
>
> Really? IMO, this process is unnecessary:
>
> - A developer sees a feature/bug that needs attention and takes the time to
> develop it, test it and submit a patch using current technology, Java 6,
> not even 7.
> - The patch is rejected because it is a Java 6 patch
> - A developer redoes the patch for Java 5 and the code is committed to trunk
> - I find that the code is still not right for Java 5 and suggest we move to
> Java 6.
> - A developer changes the code AGAIN for Java 5, finally getting it right.
>
> This shows to me that we have created -- intentionally -- an impediment for
> people to contribute to this project.
>
> Java 5 is dead and no one is forced to use a new version of this project
> that requires Java 6.
>
> Gary
>
>
>> > IMO, I do not think this requires a formal vote, but we can have one...
>> >
>> > Gary
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
