[Q] trunk stability during push to jruby 2.0

Ruby JRuby
1

I like to live dangerously. Most of my dev systems run the latest
trunk (+/- 2 days). Watching the chatter on irc indicates that 1.1.3
is likely the last of the 1.x series to get any major love; most
future development effort will be going towards 2.0 with the primary
improvement being in the Java integration.

So, my question is this: how safe will it be to track trunk going
forward?

Will all new development be done on trunk with every effort to make it
build cleanly & pass all specs prior to new checkins?

Will 2.0 be a branch with trunk acting as a potential 1.1.4
maintenance branch?

What’s the plan? Thanks…

cr

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
2

Hi Chuck,

The latest info I got is that Java Integration refactoring is not
going to be as breaking as originally was feared, and that there will
be 1.1.4 release. Charlie or Tom might correct me here.

We continue to use and run all our current tests and rubyspecs, and I
intend to do so going forward as well, fixing the remaining
compatibility problems etc. So, tracking the trunk is hopefully not
going to be problematic. I can expect that to see some regressions or
occasional problems with java integration layer, since it is being
actively changed at the moment, but hopefully there should be nothing
really major or totally incompatible.

Thanks,
–Vladimir

On Wed, Jul 23, 2008 at 3:09 PM, Chuck R. [email protected]
wrote:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
3

Vladimir S. wrote:

The latest info I got is that Java Integration refactoring is not
going to be as breaking as originally was feared, and that there will
be 1.1.4 release. Charlie or Tom might correct me here.

Yes, in an effort to better understand the intricacies of Java
integration, I started first to refactor our existing code. During that
process, it started to be clear to me that it would be possible to do a
backward compatible refactoring of the code that would improve
performance, readability, and maintainability tremendously. So far that
work has gone very well without breaking any of our existing tests/specs
and with only one reported regression which was quickly fixed. So I
think the new plan is to get this into a 1.1.4 release in short order.

We also recognize that people are using Java integration today and
didn’t want to leave people with the old mess of code for the
potentially long period it would take to rework it. And so there will
likely be additional fixes coming along with the rework…fixes we
previously had planned to do only in the new code.

For the “2.0” Java integration work, there will potentially be unstable
periods on trunk. Along with that work, there will very likely be a
rework of the whole Ruby call path to accept normal Java objects
directly, rather than requiring all objects be wrapped in a Ruby object.
This might happen in pieces on trunk, or might happen on a branch. But
we’ll be sure to coordinate with folks running on the bleeding edge to
minimize the impact. It will be a lot of work, and it won’t do to have
a broken trunk for any period of time.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
4

On Jul 23, 2008, at 10:03 AM, Vladimir S. wrote:

occasional problems with java integration layer, since it is being
actively changed at the moment, but hopefully there should be nothing
really major or totally incompatible.

Vladimir,

thanks for the clarification. I didn’t see those details on irc (I
lurk often).

I guess I’ll continue to track trunk. As I see breakage in my systems,
I’ll file bugs.

cr

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email