jashkenas / ruby-processing

Code as Art, Art as Code. Processing and Ruby are meant for each other.

Home Page:http://github.com/jashkenas/ruby-processing/wikis

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Time for a fresh start

monkstone opened this issue · comments

@fluxusfrequency @hoshi-sano @pierre-pat @poqudrof @stevekinney @tyfkda
The current version of ruby-processing is based on processing-2.2.1 which is v. mature (stable) and on jruby-1.7.* (ruby-1.9.3) also v. mature (stable). Since ruby-processing-2.6.12, it should be also be compatible with jruby-9.0.0.0 (works OK for me with rc1). I am proposing to park ruby-processing (possible after one more jruby-1.7.* release) and there will be a possibility of updating to jruby-complete-9.0.0.0 at some future stage. There is also a possibility of including processing core jars in the gem, as I had with JRubyArt, but I am not proposing to do that myself.

What I am proposing to do for processing-3.0 is to re-brand ruby-processing as JRubyArt based on jruby-9.0.0.0, there will be no backward compatibility with jruby-1.7.** (or processing-2.2.1). I plan to clobber (wipe out the commit history) of my current JRubyArt and replace it with my ruby-processing-3.0. To recognise the contributions of @jashkenas and @moumar I plan to add them to author list, but not any other authors of ruby-processing unless @jashkenas and @moumar think I should. For JRubyArt I replaced rp5 with k9 but perhaps rp3 would be better?

JRubyArt is up and running, and I have pointed direction to how to achieve compatibility for original ruby-processing with jruby-9.0.0.0, but issues remain thanks to the jruby team futzing with the class loaders. Issue may yet resolve itself, since they have already partially reverted changes that caused original incompatibilty.