Release 1.7.13 #734
Comments
|
Sounds reasonable for me. |
|
Releases are simple but the consequences of messing up are great. I'm planning to take a few weeks off, and although Rhino is mostly a hobby, I'm going to take some time off from that as well. So, I'm going to plan to push out this release in the first week of August. In the meantime, the master branch looks good and folks should keep using it and keep up the great momentum of finding and fixing bugs. We'll hold off on big changes like serialization and synchronization until after the release. |
|
I see that there is already a branch of rhino_1_8. The changes are included in this branch or in another branch "1.8"? |
|
I suspect that branch is many years old. Everything we're considering for the release is in the "master" branch. There are a few issues I recently opened up -- getting rid of serialization, and removing unnecessary sychronization -- that would stay out of master until after the next release. |
|
So to be less confusing: Let's plan for a release called "1.7.13," in the first week of August, based on what is in the "master" branch at the time. After that date, we'll start working on a release to be called "1.8". |
Enjoy - is there some hope to get PR's merged during the next weeks? |
|
I'll check in a few times during the break!
…On Wed, Jul 1, 2020 at 4:12 AM RBRi ***@***.***> wrote:
I'm planning to take a few weeks off
Enjoy - is there some hope to get PR's merged during the next weeks?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#734 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7I27KNVYTRCBDZ3CN5LLRZMKZHANCNFSM4OLOB3SQ>
.
|
Please let us think a bit about breaking the backward compatibility with this version. There are many places where we have significant differences from the spec and i see no chance to cure the problems without doing major changes to the code base. During the last year i was several times at the point not being able to fix some issues because i found no way to do it without breaking the backward compatibility. Maybe we can start working on two branches - the 1.7.x for backporting minor fixes and the 1.8 that is more like work in progress. 1.8 will be not backward compatible with 1.7 and even there will not be any backward compatibility between the various 1.8.x version for some time (maybe for one year) until the version / api is more or less stable What do you think? |
|
Do you think August is still possible for 1.7.13? We would subsequently draft a new Ringo release based on it, if the waiting period is not too far away. Getting into 1.8 looks reasonable from my perspective. I think you mean compatibility with existing Rhino-based JS, which would not affect the underlying Java-APIs too much, or? It has been great to see all your language additions in the last months. Breaking existing JavaScript code (e.g. based on JS 1.8 syntax) should legitimate and unavoidable if you want to bring Rhino to a decent level of EcmaScript support. |
|
Yes, soon, because the master branch is in pretty good shape. I have a bit
of work to do to carve out some time, however.
The compatibility question is a tricky one, because in places where
projects I've worked on use Rhino, it's part of a larger platform that runs
customer code. That means that breaking Rhino backward compatibility could
also break customer code, which means that those projects would be less
likely to take the upgrade and instead stick with old versions of Rhino.
Other JS platforms don't have this problem because they abandoned obsolete
language features years ago.
At the same time, having 10 different "supported language versions" isn't
doing anyone any favors, so we're going to need to find a more clever
solution.
…On Wed, Aug 12, 2020 at 1:11 AM Philipp Naderer-Puiu < ***@***.***> wrote:
Do you think August is still possible for 1.7.13? We would subsequently
draft a new Ringo release based on it, if the waiting period is not too far
away.
Getting into 1.8 looks reasonable from my perspective. I think you mean
compatibility with existing Rhino-based JS, which would not affect the
underlying Java-APIs too much, or? It has been great to see all your
language additions in the last months. Breaking existing JavaScript code
(e.g. based on JS 1.8 syntax) should legitimate and unavoidable if you want
to bring Rhino to a decent level of EcmaScript support.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#734 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7I24766I2OWD4OHGXDB3SAJFB3ANCNFSM4OLOB3SQ>
.
|
|
I haven't forgotten about the release. I'd like to base it on what's in master right now, unless anyone has "one more thing" -- and it should be a small thing -- to include. |
|
Nothing from my side - please go ahead. |
|
Seems like this issue can be closed, as 1.7.13 has been released half a year ago :-) But what about the comment of @rbri: #734 (comment)? I also ran into 'challenges' with how things are currently implemented when (trying to) implement Proxies and getting the proper behavior, leading me to think at some point there will have to be some breaking changes. @rbri care to elaborate on the type of breaking changes you were thinking of? I'd have to dig into my yet incomplete Proxy implementation to remember the exact issues I was running into |
|
Closing this, as 1.7.13 has long since been released |
We have a decent-sized list of things that have changed since 1.7.12 and it's a good time for a release.
We're also thinking of some more impactful things going forward, like changing Rhino's formal relationship with serialization and synchronization, adding Promises (I have a lot of the work for that ready). I also keep experimenting with performance improvements, although it is very very hard to move the needle on those.
I think that the next set of changes after this release should come in a few months and be called 1.8.0.
The text was updated successfully, but these errors were encountered: