We changed version from 3.2.x to 3.3.x quite late in the release and
this was the reason I proposed change to java 7. It allows us continue
3.3.x improvement and use new language features.
Personally I believe changing compiler configuration to target java 7 is
very unlikely to introduce regressions in Maven at this point, but I can
understand if somebody wants to do additional validation.
Making actual code changes just to show we use java 7 language features
in 3.3.0 seems unnecessary risk, however. I think it makes more sense to
release 3.3.0 as is, then do java 7 cleanup in 3.3.1.
--
Regards,
Igor
On 2015-03-07 7:26, Hervé BOUTEMY wrote:
Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit :
There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0
on Java 7 in a few weeks.
what I don't like with this plan is that it is exactly what happened with
3.1.1 then 3.2.1:
and before 2.1.0 vs 2.2.0
and the only cause (IIRC) is that we had a schedule, then thought it would be
good to upgrade, but didn't change the schedule to have 1 to 2 weeks to test
if we decide to take 2 weeks to integrate some improvements that the upgrade
permits and test, would the upgrade to 3.3.0 be ok?
Regards,
Hervé
we never did any bugfix for 3.1.1, 3.1.1 was a dead branch
for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but
who will ever do that? (not me...)
I agree that the lack of schedule can be a problem if we decide to make the
release this week-end: but if we take one week to integrate Java 7
improvements (ie mostly syntax for better maintainability and a few new
APIs) and take one week after that to test the result, IMHO we get a better
plan: a new Maven version, with features and the assurance we'll do bugfix
releases on it (the fact that it has upgraded Java requirement is just a
fact on release notes)
Regards,
Hervé
Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit :
Hi Kristian,
Please note that I am not opposed to using Java 7 in the core. What I am
objecting to is the planning, or rather the lack of it.
We currently have core ready to be released on Java 6. Then just before it
is about to be released someone says, hey lets switch Java version as
well. IMO that is something you should plan for before work is even
started
on the next release.
Then there is the agreement we made regarding Java versions and their EOL.
Switching to Java 7 before the release will mean that a fewer number of
users will be able to reap the benefits of the bugfixes and features in
Maven 3.3.0.
There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0
on Java 7 in a few weeks.
Weighing in all of this I don't see any reason to change the Java version
for 3.3.0.
Den 6 mar 2015 13:54 skrev "Kristian Rosenvold" <
[email protected]>:
I already have the full jdk7 port in a branch in github, so that
assumption
does not hold :)
Kristian
2015-03-06 13:50 GMT+01:00 Dennis Lundberg <[email protected]>:
Hi,
If we are going to release 3.3.0 very soon, like this week or the
next, there won't be any time to start using Java 7 features in the
3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and
announce, in the 3.3.0 release notes, that the 3.3.x line is the last
line that will work with Java 6. Depending on what the core developers
want to focus on after the 3.3.0 release is done, the core can either
go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This
would also be consistent with our policy [1] for plugins/components
wanting to move to a higher major Java version, in that we should
release what we currently have in trunk before upgrading to a higher
major Java version.
My votes are:
-1 for Java 7 in 3.3.0
+1 for Java 7 in 3.4.0
[1] http://maven.apache.org/developers/java6.html
On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko <[email protected]>
wrote:
With maven core version change to 3.3.0 on master, any objections I
change compile source/target to java 7?
--
Regards,
Igor
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
