sebb wrote: > I cannot see much point in trying to support BSF 2.4 going forward. > Well, there are many installations that have BSF 2.4 installed and use it, I would assume.
Usually large companies and organisation tend to be very slow in adapting newer or the latest technology, if what they have works for them. Each change costs and bears the risk of unforeseeable problems (=costs) coming up. (Believe it or not, there are still companies and products which deploy Java 1.3, although they seem to be rapidly waning!) > Seems like a lot of work for little or no gain, as JSR-223 is the future. > Yes, JSR-223 is the future, but BSF 2.4 has a past on which people may rely and count on it. > I suggest we mark all outstanding 2.4 bugs as WONT FIX. > Not yet, please! I intend (yes I know, for much too long) to fix those bugs and add the access to JRS-223 engines that ant has come up with for one of his projects. I would like to fix those bugs such that some "final" release of BSF 2.4 (2.5?) could be crafted. When releasing it we would point the people to BSF 3 and suggest to use it instead, if they are able to easily do so. > The jakarta/bsf/trunk SVN directory currently contains both the BSF > 2.x and BSF 3 code-lines, as well as some obsolete code (bsf3/old). > > This is quite confusing at first. > > Perhaps SVN can be tidied up so that BSF2 and BSF3 are in independent > directory trees? > > For example, move BSF 2.x code to a branch, and make trunk for bsf3 only. > +1 (if the BSF 2.x branch can be updated) Doing this switch gradually, pointing to/encouraging to switch to BSF 3.x and at the same time keeping BSF 2.x around for those who need it would mostlikely bear the most benefits. ---rony --------------------------------------------------------------------- To unsubscribe, e-mail: bsf-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: bsf-dev-h...@jakarta.apache.org
