Return-Path: X-Original-To: apmail-maven-dev-archive@www.apache.org Delivered-To: apmail-maven-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7807E1855B for ; Tue, 1 Dec 2015 09:14:27 +0000 (UTC) Received: (qmail 89174 invoked by uid 500); 1 Dec 2015 09:14:27 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 89084 invoked by uid 500); 1 Dec 2015 09:14:27 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 89072 invoked by uid 99); 1 Dec 2015 09:14:26 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2015 09:14:26 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 6CB0D1A11C7 for ; Tue, 1 Dec 2015 09:14:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id r1Zq_42t5nCI for ; Tue, 1 Dec 2015 09:14:15 +0000 (UTC) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 19037215CF for ; Tue, 1 Dec 2015 09:14:15 +0000 (UTC) Received: by wmww144 with SMTP id w144so163850721wmw.1 for ; Tue, 01 Dec 2015 01:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=wPop3saSBPLxdOzMLtwwIHMaqiFqiQhWPmsvnazEqN4=; b=Puvb7yZdwWYUW/qPTDhF7M6DlNcqHiYJicpX3Yv2sJ1Rw0htG/h7nIPpfnv9/Iu7nu WsQFuKnrPgLMINVXpLkBLyIynQyqLkuh7JpvFP/0XNmPDhK6geII25e8MFJFj0boTk/1 LnajV/l94gd7Lr+x4w3UGgj4KSTxOp3qFwqh6n64b3MI7ztMjnmiIHdJe0S8i6xEcxZr mkIy20ewWeSBoxiilVlg73Id/01U05xPrYXpIFHK4rOgxI21uZWMmlAAU8qO3BPLLE99 +t/IVYGWgKpdgXyfOOKEFNWhiYuPlvIxEQCMhBzm+UaXBvdcsnhlVSsE83U9tafjpa6d Ih8g== MIME-Version: 1.0 X-Received: by 10.28.35.203 with SMTP id j194mr33494868wmj.13.1448961253780; Tue, 01 Dec 2015 01:14:13 -0800 (PST) Sender: anders.g.hammar@gmail.com Received: by 10.194.240.165 with HTTP; Tue, 1 Dec 2015 01:14:13 -0800 (PST) In-Reply-To: References: <565CC6E6.3050508@apache.org> <7328A8F9-3BEB-4AAC-A1D7-DF7DA65836FD@takari.io> Date: Tue, 1 Dec 2015 10:14:13 +0100 X-Google-Sender-Auth: j-lYmwzhUcgmDJ7w4-6NWWXjm9Q Message-ID: Subject: Re: [DISCUSS] Java version requirement for Mavan 3.4.x From: Anders Hammar To: Maven Developers List Content-Type: multipart/alternative; boundary=001a113eb396d337710525d29480 --001a113eb396d337710525d29480 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My take is that if we bump version to 4.x we have to include some more (major) features other than just a requirement of Java 8 as it doesn't provide any real benefit for the user, which I'm sure they would expect from a new major version. If we would like to align Maven version with pom model version when we go model 5, we could just skip Maven 4.x and go directly to Maven 5.x. If Microsoft has done it, we can do it. :-) (Also, we skip version numbers all the time now adays with core releases...) /Anders On Tue, Dec 1, 2015 at 10:07 AM, Stephane Nicoll wrote: > I disagree. Changing system requirements in a minor release is kind of > weird so I'd rather say that the current practice is problematic. I > actually don't know the rationale to require Java8 in the codebase but if > we do it please let's label that as a major release. > > S. > > On Tue, Dec 1, 2015 at 8:10 AM, Kristian Rosenvold < > kristian.rosenvold@gmail.com> wrote: > > > Technically, JDK8 is entirely undramatic for maven; I'm having a hard > > time understanding why it should trigger any api changes or any other > > "4.0" reasons. > > > > I cannot make heads or tails of the supposed versioning policy, the > > language is too convoluted for me or I'm just not smart enough. > > > > If we are to stay aligned with current practice, jdk8 should be a > > minor release. As for the actual topic of "should" we switch, i'm > > always in favour of moving forwards. But not in any religious sense. > > > > > > Kristian > > > > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen : > > > +1 for Java 8 and the version bump to 4.x,.communicates the change mo= re > > > clearly. > > > > > > Regards > > > Mirko > > > -- > > > Sent from my mobile > > > On Nov 30, 2015 23:44, "Stephen Connolly" < > > stephen.alan.connolly@gmail.com> > > > wrote: > > > > > >> I have no issues if we want to call the next version 4.0.x rather th= an > > >> 3.4.x > > >> > > >> In my view there are some advantages to using the 4.0.x version numb= er > > as a > > >> Java 8 bump... namely that leaves the modelVersion 5.0 changes to > Maven > > 5.0 > > >> > > >> And let's face it, it will just be less confusing to users to say "T= o > > build > > >> a modelVersion 5.0 pom you need Maven 5" > > >> > > >> So if there is strong interest in jumping to Java 8 perhaps we just > bite > > >> the bullet and jump to Maven 4.0 with Java 8 now and then we can sta= rt > > the > > >> model version 5.0 debate in earnest as we plan the features for Mave= n > > 5.0 > > >> ;-) > > >> > > >> -Stephen > > >> > > >> On 30 November 2015 at 22:25, Jason van Zyl wrote: > > >> > > >> > I agree that jumping to Java 8 would be unwise. I think we can wai= t > > until > > >> > 4.x. Don=E2=80=99t get me wrong, I=E2=80=99d prefer to use Java 8 = and I do for > almost > > >> > everything else but I don=E2=80=99t think there=E2=80=99s any dire= rush. > > >> > > > >> > > On Nov 30, 2015, at 2:00 PM, Michael Osipov > > >> wrote: > > >> > > > > >> > > Am 2015-11-30 um 22:18 schrieb Stephen Connolly: > > >> > >> Picking up from > > >> > >> > > >> > > > >> > > > http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnP= nMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E > > >> > >> (and my follow up to that but archive.apache.org is being a tad > > slow) > > >> > >> > > >> > >> Here is our policy: > > >> > >> > > >> > >> The development line of Maven core should require a minimum JRE > > >> version > > >> > >>> that is no older than 18 months after the end of Oracle's publ= ic > > >> > updates > > >> > >>> for that JRE version at the time that the first version of the > > >> > development > > >> > >>> line was released, but may require a higher minimum JRE versio= n > if > > >> > other > > >> > >>> requirements dictate a higher JRE version > > >> > >> > > >> > >> > > >> > >> (Source: > > >> > >> > > >> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy > > >> > ) > > >> > >> > > >> > >> OK, so it's a draft policy... but we've all been silent on the > > draft, > > >> so > > >> > >> lazy consensus! > > >> > >> > > >> > >> Now in > > http://www.oracle.com/technetwork/java/javase/eol-135779.html > > >> > they > > >> > >> state: > > >> > >> > > >> > >> after April 2015, Oracle will not post further updates of Java = SE > > 7 to > > >> > its > > >> > >>> public download sites > > >> > >> > > >> > >> > > >> > >> So per our (draft) version number policy, we can keep Java 7 as > the > > >> > >> baseline :-( or we can choose to upgrade code to Java 8 (becaus= e > we > > >> > want to > > >> > >> use lambdas... there's a requirement) > > >> > >> > > >> > >> > > >> > >> So assuming we bump the master branch of Maven core to 3.4.0, > what > > >> Java > > >> > >> version do we want to use as the baseline? > > >> > >> > > >> > >> There are thankfully only two options: > > >> > >> > > >> > >> Java 7 > > >> > >> + Not actually changing things > > >> > >> + May make it easier to drive adoption > > >> > >> - Still can't use newer language features in core > > >> > >> - Java 7 is EOL and it may get harder for developers to sourc= e > > JDKs > > >> to > > >> > >> test and develop against > > >> > > > > >> > > Bumping Java requirements again in minor (!) release is insane. = I > am > > >> > against that, regardless Oracle has set this EoL or not. Folks at > > Commons > > >> > are doing the right this. Bump requirement with a major not a mino= r. > > >> > Moreover, we have too many components which have been neglected fo= r > > >> years, > > >> > too many outstanding issues in JIRA. E.g., Doxia, I try to fix som= e > > once > > >> in > > >> > a while but there a too few of us to take care of the entire Maven > > >> > ecosystem. > > >> > > > > >> > > I would rather see us to bringing the entire system on a decent > > level > > >> > before we make a big leaps which Java. It does not make sense to b= e > to > > >> put > > >> > Maven on the fast lane but let other components suffer at the edge > of > > the > > >> > road. > > >> > > > > >> > > Michael > > >> > > > > >> > > > > >> > > > > --------------------------------------------------------------------- > > >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > > >> > > For additional commands, e-mail: dev-help@maven.apache.org > > >> > > > > >> > > > >> > Thanks, > > >> > > > >> > Jason > > >> > > > >> > ---------------------------------------------------------- > > >> > Jason van Zyl > > >> > Founder, Takari and Apache Maven > > >> > http://twitter.com/jvanzyl > > >> > http://twitter.com/takari_io > > >> > --------------------------------------------------------- > > >> > > > >> > Be not afraid of growing slowly, be only afraid of standing still. > > >> > > > >> > -- Chinese Proverb > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > > >> > For additional commands, e-mail: dev-help@maven.apache.org > > >> > > > >> > > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > > For additional commands, e-mail: dev-help@maven.apache.org > > > > > --001a113eb396d337710525d29480--