commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Date Tue, 06 Dec 2011 05:33:26 GMT
I'm confused. Is this a vote thread or a discussion thread?  So far I've only seen +1 votes
but I may have missed others with all the noise.

Ralph

On Dec 5, 2011, at 2:45 PM, Matt Benson wrote:

> On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier <grobmeier@gmail.com> wrote:
>> On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
>>> On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier <grobmeier@gmail.com>
wrote:
>>>> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson <gudnabrsam@gmail.com>
wrote:
>>>>> I think all that Sebastian is saying is something like "if you can
>>>>> create your new, cool API and the only things you really miss from
>>>>> Java 6 are @Override on interface implementation methods and
>>>>> ServiceLoader, for example, maybe it's worth that tiny bit of extra
>>>>> pain to reach that slightly larger audience."  We all feel frustrated
>>>>> from time to time working in the community setting; I've been there
>>>>> myself, but I don't think Seb is just trying to be a killjoy just for
>>>>> the hell of it.
>>>> 
>>>> Yes, you might be right on this interpretation.
>>>> 
>>>> As long as there a volunteers for maintaining jexl2 on j5 setting, I
>>>> am fine with keeping j5 for it. To be clear, I am not saying we kill
>>>> jexl2 today or quit jdk5 support for jexl2.
>>>> 
>>>> But we should not make it a policy to start a new, major version with
>>>> the lowest JDK version possible when the actual maintainers would like
>>>> to use a current platform - this needs no discussion imho, they should
>>>> simply do as they please.
>>> 
>>> I agree that the developers of a component should do as they
>>> [collectively] please.  However, in the case of [jexl] it appears that
>>> Seb is interested in the development of this component.  He may
>>> continue to be interested in the development of a v3.x of [jexl].  Now
>>> we don't have as clear-cut a case of do-ocracy and henrib just doing
>>> what he pleases anymore, because he has to do instead "as near as he
>>> can get to what he pleases while still functioning in a
>>> consensus-based manner."  A possible sequence of events:
>>> 
>>>  - henrib proposes that [jexl] include feature X, using feature Y
>>> from Java 6, thus justifying this minimum version.  Assuming the
>>> community doesn't vote down the feature on its own merits, Java 6 it
>>> is.
>>>  - sebb can then come along say, hey, I know we agreed on feature X,
>>> but I can put in 4 hours of work or create a new Commons component to
>>> reimplement feature Y, and now Java 5 users can also benefit from
>>> [jexl] 3!
>>> 
>>> Assuming someone else is willing to do the *actual* work required to
>>> keep Java 5 compatibility, are you really going to spend time and
>>> energy fighting for interface @Overrides?  Obviously there would
>>> probably be some point at which Seb in this example would say, sure, I
>>> could reimplement feature Y, but it's going to take ten hours, twenty
>>> hours.  Not worth it; have your Java 6!
>>> 
>>> This is the way I see our community as having to function.
>> 
>> With just 2 committers on a component, is not really easy to get an
>> consens when both have different opinions. What now?
>> Henri needs to wait until Sebb gives up java5.
>> 
> 
> I don't know what to say.  Finding consensus is part of The Apache
> Way.  I guess this means all concerned parties should try and be
> reasonable and remember that this is a do-ocracy.  If Seb wants to
> make the contributions that will keep [jexl] 3x compatible with 1.5, I
> don't see that this should inconvenience Henri B. to the point that he
> should rather work elsewhere.  Again, when the burden of maintaining
> compatibility becomes too great, it will be obviously time to move to
> Java 6.
> 
> On the other hand, how long will an API redesign take?  Maybe the
> right approach is to start with Java 6, then whoever likes to can
> investigate how much work it would take to restore Java 5
> compatibility.  This could even be done with multiple mvn modules.
> 
> Matt
> 
>> ...
>> 
>> Christian
>> 
>>> 
>>> Matt
>>> 
>>>> 
>>>> Cheers
>>>> 
>>>>> 
>>>>> Matt
>>>>> 
>>>>> On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier <grobmeier@gmail.com>
wrote:
>>>>>> On Mon, Dec 5, 2011 at 7:38 PM, sebb <sebbaz@gmail.com> wrote:
>>>>>>> On 5 December 2011 18:10, henrib <henrib@apache.org> wrote:
>>>>>>>> sebb-2-2 wrote
>>>>>>>>> 
>>>>>>>>> My view is that while there is still a need for software
to be able to
>>>>>>>>> run on Java 1.5, we should not insist on requiring a
minimum of
>>>>>>>>> 1.6.*unless* there is good technical reason for doing
so.
>>>>>>>>> 
>>>>>>>> But you don't consider a good (technical) reason the fact
that the
>>>>>>>> contributor can not/does not want to incur the cost of maintaining
a JDK 1.5
>>>>>>>> on its dev platforms to be able to contribute to newer versions...
>>>>>>> 
>>>>>>> No, I don't consider that a valid reason on its own.
>>>>>> 
>>>>>> Committing should be fun. If one does not want to support JDK 1.5
he
>>>>>> goes away. Henri seems as he does not want and would like to put
>>>>>> effort in a more modern environment. In addition, how many people
can
>>>>>> you attract with a JDK 1.5 version to contribute? For me this is
valid
>>>>>> reason.
>>>>>> 
>>>>>>>> And no-one is stating that Java 1.5 is not in used in production
somewhere;
>>>>>>>> but IMHO, these are not the ones that will be JEXL3 users,
especially since
>>>>>>>> they have 2.1 (soon).
>>>>>>> 
>>>>>>>> Anyway and beyond the point, my advice to 1.5 users is that
before trying to
>>>>>>>> use "new" versions of libraries, migrating away from an unsupported/EOLed
>>>>>>>> platform should be their priority.
>>>>>>> 
>>>>>>> Indeed, ideally everyone would now be using Java 6 and Windows
users
>>>>>>> should all upgrade to Windows 7 etc.
>>>>>>> 
>>>>>>> But that is a separate issue.
>>>>>> 
>>>>>> No it is not.
>>>>>> 
>>>>>> It seems you ignore my idea on having jexl2 in maintenance mode,
but
>>>>>> this is actually what MS did with Win XP. Now they don't support
it. I
>>>>>> ask myself, why do we need to support outdated jdks until all
>>>>>> committers are gone away or the library is the outdated people get
>>>>>> some fresher stuff (Collections vs Guava)?
>>>>>> 
>>>>>> If Henri is the opinion that people should use jdk6 he should be
>>>>>> allowed to create such a version and call it Jexl3.
>>>>>> If you want to keep a jdk5 version, you are of course allowed to
>>>>>> support that one.
>>>>>> 
>>>>>> Cheers
>>>>>> Christian
>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> http://www.grobmeier.de
>>>>>> https://www.timeandbill.de
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> 
>> 
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>> 
>> ---------------------------------------------------------------------
>> 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