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 <grobme...@gmail.com> > wrote: >> On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>> On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier <grobme...@gmail.com> >>> wrote: >>>> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson <gudnabr...@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 <grobme...@gmail.com> >>>>> wrote: >>>>>> On Mon, Dec 5, 2011 at 7:38 PM, sebb <seb...@gmail.com> wrote: >>>>>>> On 5 December 2011 18:10, henrib <hen...@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-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://www.grobmeier.de >>>>>> https://www.timeandbill.de >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> http://www.grobmeier.de >>>> https://www.timeandbill.de >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
