jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <>
Subject Re: [VOTE] Release JMeter 5.2 RC4
Date Thu, 24 Oct 2019 19:45:57 GMT
As Philippe finds it useful too. I will vote


We should do another rc.

@vladimir is the release plugin ready to use with the changed sha512 files? 


Am 24. Oktober 2019 21:23:27 MESZ schrieb Milamber <>:
>I can cancel the RC4 vote or a PMC member can put a -1 (veto) to the 
>Currently if I count my (future) vote +1 and the 2 +1 from Vladimir and
>Philippe, the RC4 will pass the vote.
>What is your (PMC member) preference?
>On 23/10/2019 16:28, Philippe Mouawad wrote:
>> Hello,
>> I think we should do another rc restoring browser component.
>> I find it helpful when debugging a script.
>> So unless there is a blocker, it should be restored.
>> Thanks
>> On Wednesday, October 23, 2019, Felix Schumacher <
>>> wrote:
>>> Am 23.10.19 um 15:12 schrieb Vladimir Sitnikov:
>>>>> I already use the Oracle Java 8 to build the releases (RC4
>>>> Well. By "Require release manager" I mean **every** release
>>>> For instance, I have not purchased Java license from Oracle. Does
>>> mean
>>>> I must buy one in order to be the release manager?
>>> You don't have to buy a license to use the last openly available JDK
>>> from Oracle. But it might be difficult to download it. (I found a
>>> to the archive under the FAQ from the download for Java 8.
>>> )
>>>> The next question is what if someone downloads JMeter sources and
>>> to
>>>> build it?
>>> That depends -- as earlier -- on the version of used Java. At the
>>> you will only get a working JavaFX control, if you use Oracle JDK 8
>>> (plus the parameter).
>>>> Does that mean they must use Oracle Java?
>>> No (if they are not interested in that special control)
>>>> Does that mean they should get build failure when using builds like
>>>> AdoptOpenJDK?
>>> No (it didn't with the ant build -- I think we checked for a JavaFX
>>> class on the classpath to decide whether we should compile it)
>>>> The current implementation is "JavaFX opt-in".
>>> At the moment I tend to include it on building the release, but I
>>> sympathy with your arguments, that JavaFX is really difficult to use
>>> build/run time.
>>> I am less sure with every time we are talking about it, that it is
>>> valuable enough to keep the feature.
>>> But if we drop it now from the release, we should mention it in the
>>> change logs and hope that someone comes up with an alternative, that
>>> can include some day.
>>> Felix
>>>> Vladimir

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message