Robert> According to the ASF the -sources.zip are the official release, not
the git tag
That's right
Robert>In this case you don't control the EOL, it is based on the OS of the
release manager.
Is it? I would disagree here.
For instance, Apache JMeter produces both -src.zip (CRLF), and
Hi Robert,
having put some more thought into it I was thinking: maybe the IT
should prove that the jira issue integrates with the plugin. In that
case the name would be OK and I would also have a path for providing an
IT for MRELEASE-229. As of now there are no ITs for release:rollback.
Hi Robert,
thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even
with this parameter since the backport for TLSv1.2 came with Update 95 [0]?
Since when does this requirement exist? Just checked it: I'm using UK
mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
The plugin is indeed still Java 7 compatible, but that means you must
execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7,
otherwise it'll fail because this is a requirement when downloading from
Central.
Our CI server scripts already add this argument when running with
Hi Clemens,
since the codebase is already rather old, you'll see that naming
convention has changed over the years.
Nowadays I prefer to to start with the JIRA id, followed by a very short
statement of the IT.
In the end I'm more important that there is at least a test than the name.
Just
Keep in mind there's another important situation that you can't control it like
this.
According to the ASF the -sources.zip are the official release, not the git
tag. This means that you should unpack the zip and be able to verify it on all
OSes.
In this case you don't control the EOL, it is
Hi Robert ,
Any issues to report on JDK 13 , would like to hear the status as we are
now in rampdown phase 2 ?
**OpenJDK builds *- JDK 13 Early Access build 30 **is now available **at
: - jdk.java.net/13/*
* Per the JDK 13 schedule [1], we are now in Rampdown Phase Two.
o For more
