Re: Blockers for next release?

[Felix Schumacher]

Am 31.03.26 um 18:57 schrieb Vladimir Sitnikov:

Are there any blockers, that would hinder us from releasing a 6.0 version?

Frankly, I have been working on 6389 since November, and currently I
implement generic "explicitly unset" vs "set to empty" for text-like and
combobox controls.
I don't remember why it was required, however, it looks like it is required
so "http defaults" do not override the values in http sampler unless the
user explicitly asked for it.
It might be fine to postpone the 6389 and "explicitly unset" to a
subsequent release.

Well, users will expect a .0 version to contain bugs, right?

No, do you have an estimate how much work is still needed? Can anyone help you out with some tasks?

* I would like to switch off oro by default (PR 6661), any reason not to

do so? (There is one question hidden in the PR :) )

What do you mean by "switch off by default"?
I would like to avoid introducing breaking changes as much as possible.
Ideally, the script designed for old versions should be workable with newer
versions just fine.

In 5.6 (i don't remember the exact version), we introduced a switch to use Java regex instead of oro, with the default being oro. Now with 6.0 I think it is a good time to reverse that and use Java regex as the default while the user can still enable oro back, if he likes.

I don't think that the regex implementations differ that much, except that Java regex is more feature rich and probably better tested. With a next major version we could then (if we don't get too many complaints) remove oro completely. The question I have is more about the change in the escapeOroRegex function, where I boldly assume, that a user wants to use that function even with Java regex enabled, but we want to pave the way for removal of oro. So that function uses Java regex quote functionality instead of oro, when Java regex is enabled.

* PR 6610 seems to be a no-brainer, but haven't looked too closely
* We distribute rhino in version 1.8, but as we don't include

rhino-engine, we can't select js in JSR223 elements. I think, we should add
that missing jar (or even add nashorn, now that we have Java 17 as minimum)

Unfortunately, the syntax between rhino and nashorn differs, so we can't
replace one with another without breaking the users' scripts.
If we can't select rhino in JSR223, that sounds like a bug, and we should
probably add rhino-engine. Nice catch.

Well, we already were on nashorn, way back, when it was in the JDK, so going back to rhino is a breaking change for these people :)

But I don't mind either way, as I think groovy is way better suited for scripting in JMeter anyway.

The discussion with virtual threads and Java 21 should be (in my opinion)

deferred to the next version after 6.0.

Fair, I do not think it should hold the release.

Vladimir

Felix

OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature