Timeline for next release

[midgleyc]

It's been about a year and a half since the last release: would it be possible to release a snapshot or release candidate on the way to 1.7.15?

[gbrail]

What would people think if we did a release in the next two weeks or so, based on what's currently in the repo?

After that I'd like to re-open discussions about making more drastic changes to this project, and I think I will have a little bit of time to make them.

[p-bakker]

Personally, I'd like to at least achieve the following in a backwards-compatible branch:

• fix const implementation
• add support for u flag in Regex

Now, this is not to say that we cannot do a release shortly, but for both these issues I've done a lot of work already, but neither are finished as I haven't had time to work on them for a long while. Hoping to be able to wrap them up in the next 2 to 3 months though

[gbrail]

OK folks -- I said "two weeks ago" in August. I think that things are quiet now -- isn't it time for a new release?

After the new release, I'd like to push a PR I'm working on that restructures the codebase, and which will make Rhino require Java 11+ going forward -- I think that puts Rhino in line with other major Java libraries.

I've been merging new changes into the "restructuring" PR for a while now, and git is actually pretty good at merging old PRs even if the structure changed, so it's not going to break everyone when we do that.

After that we will discuss whether breaking backward compatibility is something that we could ever consider.

Let me know what you think below!

[p-bakker]

Whether to do a release now or not imho depends on what we want to/can do afterwards. I don't think the project is currently in a state where we can make a jump to a v2.0.0 that contains breaking changes for embedders, if we're gonna stop the development on v1.7.x

Let me explain myself: On the path to becoming EcmaScript-compliant I foresee us having to make breaking changes to some interfaces, like the Callable and Scriptable interface
Given that I do not think we're in a great position (resources-wise) to maintain 2 versions in parallel, I feel we should try to get as much into the v1.7.x branch as we can, before cutting over to a non-backwards-compatible v2.x.x branch, as I think many embedders of Rhino might take a while to upgrade to a v2.x.x branch if that isn't a drop-in replacement and as such they'd be stuck on the v1.7.x branch which wouldn't see any EcmaScript compatibility improvements

Now, I do not know if your changes to restructure the codebase and make Rhino require Java 11+ would result in backward-incompatible changes (except from dropping <Java 11 support) or not. If not, I'm fine doing a 1.7.15 release soon, followed by a 1.7.16 including your codebase restructure/Java 11+ requirement somewhere in the future

[midgleyc]

I would appreciate a 1.7.15 whether or not any further changes go into a hypothetical 1.7.16 or 2.0.0.

I am personally fine with requiring Java 11 -- we're requiring Java 17 ourselves.

[michbarsinai]

I'm happy with requiring JDK11+. We currently require that anyway, and we consider moving on to JDK21+ later this year. IMHO having a new release is important even just to show that the project is alive and well. Restructuring etc. can be done after that.

(important) Also - thanks for all your work on this!

[kokhoor]

Any follow up on this? Are there any plans to release soon?