You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Milamber <mi...@apache.org> on 2023/06/29 16:12:07 UTC
[VOTE] Release JMeter 5.6.1 RC1
Hello,
The first release candidate for JMeter 5.6.1 (2fcc6fd625) has been
prepared, and your votes are solicited.
JMeter is a Java desktop application designed to load test functional
behavior and measure performance. The current version targets Java 8+
This release brings some new features and improvements, and also fixes 2
regressions since v5.6.
Please, test this release candidate (with load tests and/or functional
tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
Feedback is very welcome within the next 72 hours.
You can read the New and Noteworthy section to see improvements and full
list of changes at:
https://apache.github.io/jmeter-site-preview/site/changes.html
Download - Archives/hashes/sigs:
https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.6.1-rc1
(dist revision 62740)
RAT report:
https://apache.github.io/jmeter-site-preview/rat/
SHA512 hashes of archives for this vote: see footnote [1]
Site preview is here:
https://apache.github.io/jmeter-site-preview/site/
JavaDoc API preview is here:
https://apache.github.io/jmeter-site-preview/site/api/
Maven staging repository is accessible here:
https://repository.apache.org/content/repositories/orgapachejmeter-1085/org/apache/jmeter/
Tag:
https://github.com/apache/jmeter/releases/tag/v5.6.1-rc1
Keys are here:
https://www.apache.org/dist/jmeter/KEYS
N.B.
To create the distribution and test JMeter: "./gradlew build -Prelease
-PskipSign".
JMeter 5.6.1 requires Java 8 or later to run.
The artifacts were built with
Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_361-b09)
Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
25.361-b09, mixed mode)
Some known issues and incompatible changes are listed on changes page.
https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
All feedback and vote are welcome.
[ ] +1 I support this release
[ ] +0 I am OK with this release
[ ] -0 OK, but....
[ ] -1 I do not support this release (please indicate why)
The vote will remain open for at least 72 hours.
The PMC members please indicate the mention "(binding)" with your vote.
Note: If the vote passes, the intention is to release the archive files
and rename the RC tag as the release tag.
Thanks in advance!
Milamber
===
[1] SHA512 hashes of archives for this vote:
4dec17f735e701c701624d88ea91018fa83f1b4dd633c2b0638f96cef2016c006676a235b4f5cc9e71e8503c8133cf28010f593ac52d0b45e4aecaab1edf4313
*apache-jmeter-5.6.1.tgz
536c3fb6f37ba3f8e477953919628629927c30f5dc7f2f3d75e6e9fc855d5e76770b5b990659a0c4ea633dfc29e6f4bdb62d3de44ae4db4c72a7d8c2067bdf3c
*apache-jmeter-5.6.1.zip
946cd11e7003a883904124e9012acf163f35c325b515f95ad491b7f4ec670de98158f8a18d86c2252f4906507e24c808fa70edf7410bbf5c48b1fe4fca19cafb
*apache-jmeter-5.6.1_src.tgz
695344876ee7a830b0ade499961ea7980868528212b73e87ff7ac738a49561df6c26157083343e9eef0f7097e004a03469bf29d6ee842db753a1c072f7100ebd
*apache-jmeter-5.6.1_src.zip
Re: [VOTE] Release JMeter 5.6.1 RC1
Posted by Milamber <mi...@apache.org>.
Hi
I stop the vote, and start to prepare a new RC for 5.6.1 with the PR6027.
Milamber
On 29/06/2023 17:12, Milamber wrote:
> Hello,
>
> The first release candidate for JMeter 5.6.1 (2fcc6fd625) has been
> prepared, and your votes are solicited.
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> This release brings some new features and improvements, and also fixes
> 2 regressions since v5.6.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section to see improvements and
> full list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.6.1-rc1
> (dist revision 62740)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
> https://repository.apache.org/content/repositories/orgapachejmeter-1085/org/apache/jmeter/
>
>
> Tag:
> https://github.com/apache/jmeter/releases/tag/v5.6.1-rc1
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.6.1 requires Java 8 or later to run.
>
> The artifacts were built with
> Java(TM) SE Runtime Environment Oracle Corporation (build
> 1.8.0_361-b09)
> Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.361-b09, mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
>
> All feedback and vote are welcome.
>
> [ ] +1 I support this release
> [ ] +0 I am OK with this release
> [ ] -0 OK, but....
> [ ] -1 I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
> 4dec17f735e701c701624d88ea91018fa83f1b4dd633c2b0638f96cef2016c006676a235b4f5cc9e71e8503c8133cf28010f593ac52d0b45e4aecaab1edf4313
>
> *apache-jmeter-5.6.1.tgz
> 536c3fb6f37ba3f8e477953919628629927c30f5dc7f2f3d75e6e9fc855d5e76770b5b990659a0c4ea633dfc29e6f4bdb62d3de44ae4db4c72a7d8c2067bdf3c
>
> *apache-jmeter-5.6.1.zip
> 946cd11e7003a883904124e9012acf163f35c325b515f95ad491b7f4ec670de98158f8a18d86c2252f4906507e24c808fa70edf7410bbf5c48b1fe4fca19cafb
>
> *apache-jmeter-5.6.1_src.tgz
> 695344876ee7a830b0ade499961ea7980868528212b73e87ff7ac738a49561df6c26157083343e9eef0f7097e004a03469bf29d6ee842db753a1c072f7100ebd
>
> *apache-jmeter-5.6.1_src.zip
>
>
>
>
>
>
Re: [VOTE] Release JMeter 5.6.1 RC1
Posted by Milamber <mi...@apache.org>.
On 30/06/2023 17:38, Vladimir Sitnikov wrote:
> There's a question on displaying default values in UI:
> https://github.com/apache/jmeter/issues/6026
> They say it is confusing to see the defaults in "HTTP Request Defaults"
> since the user can't tell if it will overwrite HTTP request or not.
>
> I agree it is confusing, and it brings a new question: can we really "omit
> saving default values"?
> In other words, if we omit saving the defaults, then we won't be able to
> tell if user intentionally sets the value to UTF-8 or not.
>
> As a quick WA I suggest PR https://github.com/apache/jmeter/pull/6027 ,
Seems a good start to improve the behavior.
> however, we probably need to adjust "default vs unset" behaviour later,
> especially for checkbox-like elements where it is hard to tell if the unset
> value is intentionally blank or if it is just a default.
+1
>
> I guess we need to cancel the vote, merge something like 6027 and create RC2
No need to cancel the vote, just stop it and restart a new vote with RC2
(that I will prepare)
Milamber
>
> ---
>
> One of the solutions could be:
> * treat blank text field as an intention to "remove property" (==PR6027)
> * treat non-blank field as an intention to "keep exactly that
> value" (==PR6027)
> * It is not clear what to do with checkboxes though
> I believe it is super confusing if "empty checkbox in HTTP Request Default"
> should override a "filled checkbox in HTTP Request Sampler".
> In other words, for text fields it is unlikely people would need
> "intentionally blank values", so we can treat "blank fields" as if user
> wants clearing the value.
> However, for checkboxes, they would need both "just use default" or
> "intentionally unsed checkbox".
> * A similar question exists for radio buttons: how do we identify which was
> just left intact vs which was intentionally selected
>
> It becomes challenging at the API level as well: is
> TestElement.setProperty(key, null) and intentionally set blank value, or
> could it remove property instead?
> Should TestElement.setProperty(key, "") be treated differently from
> TestElement.setProperty(key, null)?
>
> I guess, the ideal case is that UI components should track which fields
> were modified, and save only the modified fields to the element properties.
>
> Vladimir
>
Re: [VOTE] Release JMeter 5.6.1 RC1
Posted by Vladimir Sitnikov <si...@gmail.com>.
There's a question on displaying default values in UI:
https://github.com/apache/jmeter/issues/6026
They say it is confusing to see the defaults in "HTTP Request Defaults"
since the user can't tell if it will overwrite HTTP request or not.
I agree it is confusing, and it brings a new question: can we really "omit
saving default values"?
In other words, if we omit saving the defaults, then we won't be able to
tell if user intentionally sets the value to UTF-8 or not.
As a quick WA I suggest PR https://github.com/apache/jmeter/pull/6027 ,
however, we probably need to adjust "default vs unset" behaviour later,
especially for checkbox-like elements where it is hard to tell if the unset
value is intentionally blank or if it is just a default.
I guess we need to cancel the vote, merge something like 6027 and create RC2
---
One of the solutions could be:
* treat blank text field as an intention to "remove property" (==PR6027)
* treat non-blank field as an intention to "keep exactly that
value" (==PR6027)
* It is not clear what to do with checkboxes though
I believe it is super confusing if "empty checkbox in HTTP Request Default"
should override a "filled checkbox in HTTP Request Sampler".
In other words, for text fields it is unlikely people would need
"intentionally blank values", so we can treat "blank fields" as if user
wants clearing the value.
However, for checkboxes, they would need both "just use default" or
"intentionally unsed checkbox".
* A similar question exists for radio buttons: how do we identify which was
just left intact vs which was intentionally selected
It becomes challenging at the API level as well: is
TestElement.setProperty(key, null) and intentionally set blank value, or
could it remove property instead?
Should TestElement.setProperty(key, "") be treated differently from
TestElement.setProperty(key, null)?
I guess, the ideal case is that UI components should track which fields
were modified, and save only the modified fields to the element properties.
Vladimir
Re: [VOTE] Release JMeter 5.6.1 RC1
Posted by NaveenKumar Namachivayam <ca...@gmail.com>.
+1 binding
On Jun 30, 2023 at 12:00 AM +0530, Vladimir Sitnikov <si...@gmail.com>, wrote:
> Thanks for preparing the release,
>
> +1 (binding)
>
> I checked apache-jmeter-5.6.1.tgz with macos and Java 11: checksums,
> pgp, http proxy.
>
> Vladimir
Re: [VOTE] Release JMeter 5.6.1 RC1
Posted by Vladimir Sitnikov <si...@gmail.com>.
Thanks for preparing the release,
+1 (binding)
I checked apache-jmeter-5.6.1.tgz with macos and Java 11: checksums,
pgp, http proxy.
Vladimir