Changes to allow testing of a full matrix in Travis CI

[petergoldstein]

1. Update Appraisals, move off rc/beta releases
2. Remove .lock files from repo, so these can be rebuilt for the Ruby version being used
3. Remove explicit reference to NamedScope, just use ActiveRecord version to determine test applicability.
4. Break out the ActiveRecord and ActiveModel gemfiles by major version, so we can exclude matrix items as needed for unsupported Rubies.
5. Add JRuby ActiveRecord 4 support.

The matrix is all green, except for a set of ActiveRecord 4.0 failures that seem to be related to this issue - https://github.com/pluginaweek/state_machine/issues/248 - initial values are being set on the AR instance, but not being persisted during the intiial save.

I'm baffled, because as far as I can tell the issue should be resolved. But nonetheless the specs are failing. Any insight would be appreciated.

[petergoldstein]

Regarding my comment about the failing specs, now they seem to be passing. I'm not sure what I was doing before that was causing failures, but this merged branch is now clean and green.

[ghost]

Should this be updated http://www.ready4rails4.net based on this fix?

[petergoldstein]

@mgauthier-joist Maybe. Honestly, this PR is pretty old at this point. At a minimum I'd like to see it merged into master and tested on Travis with newer AR 4.0.x versions before I'd say the gem is 'ready' for Rails 4.

[mike-stewart]

Is state_machine ready for Rails 4 yet? I'm looking into upgrading a project that uses state_machine to rails 4.1, so I'm wondering if it will cause any problems.

[seuros]

Not from rubygems, you either need the initalizer hack or you can use my fork.

[petergoldstein]

@mike-stewart At this point I'd consider state_machine abandonware, and suggest you migrate to a better maintained gem. It hasn't seen any updates since May 2013, and doesn't show any signs of active maintenance. And it doesn't support Rails 4.x (4.0.x, 4.1.x, 4.2.x), which means that when Rails 4.2.x goes final this gem will not work with any actively supported version of Rails.

[johannesluedke]

@petergoldstein Which alternatives could be used?

[johannesluedke]

@petergoldstein As I am seeing it now, state_machine is 2years after rails4 realse still the most used state machine for rails. I think the problem that got the failures mentioned in your message from 17 Aug 2013 have been fixed on rails side https://github.com/rails/rails/pull/9489 (/see https://github.com/pluginaweek/state_machine/issues/248) And on the same day where you posted the tests were passing again.

If these failing and then passing tests were the only clue; and for everybody working with state_machine in rails4 it works, I think we should consider state_machine rails4 compatible. (It's not maintained any more though, so at one point the chang to aasm or similiar might be necessary)

[seuros]

@johannesluedke : https://github.com/state-machines

[johannesluedke]

@seuros here is a good overview (I found in the mean time) https://www.ruby-toolbox.com/categories/state_machines

You can see that state_machine is still number one with 5.1m downloads, followed by aasm with just 1.7m

[seuros]

@johannesluedke When you have an existent code base, you better switch from state_machine to state_machines since the later has the same DSL. In fact it the same codebase but cleaner, with bug fixes and more maintainers.

[johannesluedke]

Uhh cool! Didn't saw this one so far (Link http://github.com/state-machines/state_machines/). And you seem to be the main creator? Thanks for the work (y) Did you fork or create from scratch?

[seuros]

I just dropped support for old versions of activerecord, mongodb, rubies and extracted the integrations into separate gems so they can be upgraded/reworked without breaking the core gem, i also made sure to invite some known OSS contributors to the org so they can take over in case I get kidnapped by ISIS for not naming the gem IslamicStateMachine :trollface:.