Drop support for BSF 2.4? Re-organise BSF SVN?

[sebb <se...@gmail.com>]

I cannot see much point in trying to support BSF 2.4 going forward.
Seems like a lot of work for little or no gain, as JSR-223 is the future.
I suggest we mark all outstanding 2.4 bugs as WONT FIX.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org

Re: Drop support for BSF 2.4? Re-organise BSF SVN?

[sebb <se...@gmail.com>]

On 01/08/2009, Rony G. Flatscher <Ro...@wu-wien.ac.at> wrote:
> 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!)
>

Point taken.

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

OK.

There are probably some that are not worth fixing though, e.g. BSF-14 and BSF-15

>  > 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)

Yes - it's only tags that are read-only (but even that is by convention only)

Branches are often used for parallel development.

Not quite sure how best to handle the site documentation yet, as that
needs to cover both 2.x and 3.x. At present the site is mostly about
BSF 2.x.

I think leave the site in trunk for now.

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

OK.

Just to clarify, I was not proposing removing access to BSF 2.x, just
leaving it dormant.

But I'm happy to help with releasing BSF 2.5 and BSF 3.0 (final)

>  ---rony
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
>  For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org

Re: Drop support for BSF 2.4? Re-organise BSF SVN?

["Rony G. Flatscher" <Ro...@wu-wien.ac.at>]

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-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org