-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blockers for v3.0.0 Release #720
Comments
The core outstanding issues tally up to 19 and if we include the GUI defects there are 27 remaining. Getting these crunched, especially the sourceforge issues, are still a priority. I do feel the issues remaining on #694 are critical, perhaps not the late binding perse but the reload of types changed is a real nuisance. It would of course help if I had even the slightest clue how we are going to resolve them, made several attempts already but they all went There does seem to still be more nagging issues that keep popping up, which haven't been reported yet, it would be a bonus if we can get more exposure of the SNAPSHOT release to get reports on the most obvious dents to hammer down. Especially some feedback on what 3.0.0 does to existing 2.b workloads would be helpful to know. This will really go a long way to ensure a stable release... |
I am still not able to use V3 for my workloads. It is a combination of small issues (like #725 and #726), deeper issues (#659) and planned incompatibilities (e.g. variable scoping changes). I know that the small issues will get fixed, and so will #659 eventually. The variable scoping change will bite on large code bases. For people who are using V2 scripts that someone else has developed this will be a big pain point. I would like to implement a compatibility flag (with a default value of false) that will allow the previous V2 behaviour. Think of this as a transitional mode to help people make the switch. New code will use the new scoping rules. Old code can set the compatibility flag in order to run correctly without requiring changes. I have had a look and this can be implemented as a small non-intrusive change. If I send in a PR for this would it be considered? |
It is not a small change.
Adding the If this is all that breaks I am sure we will be forgiven. There really is no good reason why this is acceptable scope usage, may as well throw braces away completely. |
Seems to be a small non-intrusive change, have a look at #727. Could you help me out and explain what I overlooked that makes this more than a small change?
Ya, no. Adding |
I think you mean #728
If you can't change the code, why change the interpreter? You want to use BeanShell 3.0 because you want to use the new features, right? If you can change the interpreter, you should be able to change how the interpreter receives the code. Which is only one step away from changing the code, before the interpreter sees it. I'm thinking regex...and you don't have to make changes to the code base. |
I think you are using number of files touched as the wrong metric here. The bulk of the lines changed have to do with switching the declared type of the
Not really. I'm not likely to use many of the new BeanShell 3.0 features and as we have discussed elsewhere I disagree with many of them. I do appreciate the many bugfixes, the infrastructure upgrades (maven and test suites), working with Java9+, varargs, try with resources, enums, multi-line strings and perhaps a few other changes over bsh-2.0b6. I also like working with others in a project rather than just going it alone. Forking off my own version seems like such a big wasteful duplication of resources when there are very few of us working on BeanShell as it is. It seems losing momentum is something that the BeanShell project cannot afford, so I have been hanging in there.
So how does this work? I patch my version of BeanShell so that anytime the interpreter reads in code (e.g. |
No, use regex to patch the source you "can not access to make changes", on the fly i.o.w. before beanshell receives the source. No mention of maintaining forks. |
Is see that there are some bugs noted, but are there any real blockers holding up a v3.0.0 release?
The text was updated successfully, but these errors were encountered: