>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. >* 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. > * 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. >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
