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
