Is this gem no longer maintained? EOM

Question

Is this gem no longer maintained? EOM

cscairns opened this issue 11 years ago · 49 comments

cscairns commented 11 years ago

mensfeld commented 11 years ago

+1

pchaganti commented 11 years ago

👍

alouanemed commented 10 years ago

👍

Answer 1 · 2014-04-23T13:50:47.000Z

Very good question. I would love to help fix #277, if there was any indication that a maintainer would merge the fix if it would be good.

Answer 2 · 2014-04-25T03:23:50.000Z

someone should just fork it and take it over

Answer 3 · 2014-04-25T11:14:14.000Z

I hate to run roughshod over the original author, but I am considering doing just that. My situation is I have a Rails 3.2 app using StateMachine in a mature component but I need it to continue to working as I upgrade to Rails 4, 4.1 and beyond. The question is whether to fork this and fix the problems I'm already seeing, or whether to migrate to a different state machine gem. There seems to be a critical mass of people here who might be able to help contribute, but I'm concerned about the architecture and whether it will fit well in rails 4 world, and whether I want to get involved maintaining heavyweight support for multiple ORMs when I only care about ActiveRecord.

Answer 4 · 2014-04-25T15:34:45.000Z

I can take over this gem but i will have to drop support for old rubies < 1.9.3 . I also started rewriting the test to rspec.

You can use my fork for the ActiveRecord 4.1 issue.

Answer 5 · 2014-04-25T15:40:41.000Z

Hope this is not another 'CanCan' situation.
+1

Answer 6 · 2014-04-25T21:38:53.000Z

Likewise, this gem is a critical component of my app and it's holding-up my migration to Rails 4. May have to rip it out unless it gets some life.

Answer 7 · 2014-05-06T14:42:17.000Z

Rails 4.1 here and still working well. Indeed, we need a fork on this..

Answer 8 · 2014-05-12T09:41:56.000Z

It works with 4.0 but in 4.1 tests explode. Didn't have time to look into it yet.

Answer 9 · 2014-05-13T13:00:38.000Z

this look like a really nice option and is highly recommended. Should I start using it or would I be better off looking somewhere else ? A failing build can't be a good sign ?

Answer 10 · 2014-05-13T17:54:49.000Z

+1. @obrie ?

Answer 11 · 2014-05-14T10:04:36.000Z

👍 i would love to have a fork of this gem being still maintained !

Answer 12 · 2014-05-14T13:20:18.000Z

Hey guys, I've reached out to Aaron, and he assures me that he is not abandoning the project, but just needed some time away for personal reasons. Given the amazing work he has given us pretty much solo over several years, can I propose we give him some time and show our support by doing some testing and review on open PRs with +1s and "tested this in my app and it works, etc"?

Answer 13 · 2014-05-21T17:13:41.000Z

@gtd & @seuros can Aaron just add you as collaborators to keep things moving while he takes a break?

Answer 14 · 2014-05-21T17:17:30.000Z

Yeah , sure.

Answer 15 · 2014-05-21T20:19:39.000Z

If he reaches out to me I'm happy to help, but I probably won't be able to churn through a lot of tickets as my day job is pretty demanding.

Answer 16 · 2014-05-24T10:20:21.000Z

such a pity, I've had to switch to AASM

Answer 17 · 2014-05-26T14:24:13.000Z

@dongennl how was the migration from this gem to AASM?

Answer 18 · 2014-05-27T16:01:37.000Z

@cscairns Hi, it was very easy, bit of find and replace really. The reason I switched to this one earlier was that it supports multiple state machines on one class, AASM doesn't, but I don't need that for my current project, and I need Rails 4.1 more!

Answer 19 · 2014-06-02T21:20:55.000Z

In case anyone is his personal friend and/or has already contributed to the gem and would like to maintain it, please ask him for collaborator privileges.

Answer 20 · 2014-06-03T15:35:30.000Z

I would also look at https://github.com/peter-murach/finite_machine because it does not hook directly in ORMs and relies on pure Ruby, so it may not break when updating Rails or ORMs.

Answer 21 · 2014-06-08T20:10:35.000Z

+1 for @gtd and @seuros as collaborators.

@seuros: Does your fork still work on rails 4.1? Looks like it's been a while since you touched it.

Answer 22 · 2014-06-08T20:27:46.000Z

Yes it does. All patches are applied.

Answer 23 · 2014-07-28T21:56:21.000Z

@obrie would you mind granting someone else, say @seuros gem publishing rights? I currently use his fork, as do many others, and it's very troublesome to have to depend on a non-rubygems source.

Increasing the bus factor can only be a good thing.

Answer 24 · 2014-10-20T21:45:35.000Z

It may be time to simply take @seuros' fork and publish it as a new gem...

Answer 25 · 2014-10-20T22:12:00.000Z

I need to fix little bug for AR 4.2 first, i will do that next week. sorry.

Answer 26 · 2014-10-21T17:58:38.000Z

@seuros Thank you for doing all this work, our team is greatly appreciative! Let me know when you publish a new gem, I'll be glad to blog/tweet about it.

Answer 27 · 2014-11-22T07:27:13.000Z

Have an idea about mainaining #331

Answer 28 · 2014-11-24T14:16:20.000Z

@seuros Do you know if Issue #314 is fixed on your branch?

And thanks again for your work. Let us know as soon as you republish this!

Answer 29 · 2014-11-24T14:32:09.000Z

AFAIK yes. if not, i will fix it.

Answer 30 · 2014-12-22T09:07:40.000Z

@seuros I tried your master branch, and #314 still exist.

I still get uninitialized state on the model.new

Answer 31 · 2015-01-15T20:31:39.000Z

The Spree project relies heavily on state_machine, and we are going to release our own fork for now:
https://github.com/spree-contrib/state_machine

We don't really have time to manage a canonical fork of this project, but if no one else is going to we're going to maintain a much smaller version for Rails 4.2+. We also only currently require ActiveModel/ActiveRecord support so we may drop the other ORM's as well if they become a problem. If people would be interested in helping to maintain a fork, such as, this one or would be interested in us using their own fork let me know.

Answer 32 · 2015-01-15T20:34:34.000Z

@seuros if you haven't already are you planning to do a stable gem release?

Answer 33 · 2015-01-15T20:37:40.000Z

Did you see this work : https://github.com/state-machines/ ? I'm using the activemodel integration in a personal project without any issue ! :)

Answer 34 · 2015-01-15T20:40:41.000Z

Oh nice no I hadn't @alouanemed will have to try that out.

Answer 35 · 2015-01-15T20:46:10.000Z

We had switched to https://github.com/aasm/aasm, but that looks a little more compatible.

Answer 36 · 2015-01-15T20:53:44.000Z

No stable gem release to depend on... Looks like it would work if I didn't have to point to the git repo.

Answer 37 · 2015-01-15T21:00:25.000Z

@JDutil , i can release an alpha, there are still few bugs with AR42 integration and internalization.

Answer 38 · 2015-01-15T21:58:24.000Z

@seuros that would be good after incorporating some of the fixes we needed:
#333

Answer 39 · 2015-01-15T22:44:49.000Z

@JDutil , #333 break most of the test suite and remove features.

Answer 40 · 2015-01-15T23:13:51.000Z

Hmm might have been other commits not in there:
https://github.com/spree-contrib/state_machine/commit/d7b298e155e6e6023096105694a57891ae0cdd3c
https://github.com/spree-contrib/state_machine/commit/8a08e9e75162d13218be382bbae36019e3d7cd50
https://github.com/spree-contrib/state_machine/commit/1c31e969e740dab53f3d6b8a91ebf4c8fb8472fb

We did start removing features we don't need for Spree, but would prefer not to have to. Will see if we can get the remaining specs passing.

Answer 41 · 2015-01-30T18:29:03.000Z

So theres state-machines/state_machines-activerecord and spree-contrib/state_machine now.
Where to go to?

Answer 42 · 2015-01-30T18:56:50.000Z

spree-contrib/state_machine is going away we will be using state-machines/state_machines-activerecord

Answer 43 · 2015-02-23T01:38:01.000Z

@seuros I can help maintain this if you want. I want to build on top of the rspec for this. Let me know if there's anything I can do for you.

Answer 44 · 2017-06-08T09:36:50.000Z

So a few years down the line... @seuros: I see your fork seems to be the most current of all the forks. Can you consider releasing a stable gem version of your own and integrating the pull requests that are around here, or is everyones consensus that state-machines/state_machines-activerecord is the way to go?

I've inherited an ancient code base that uses state_machine a lot, and currently points to an arbitrary master/head of one of the many forks. Since the code base needs to be modernized anyway, it would be good to know if it makes sense to hold out with this state machine implementation as long as it works, or if I need to migrate somewhere else in order to be future proof.

(Needless to say, that state_machine still works after that long a time without much maintanence speaks for the quality of the implementation. Good job @pluginaweek :) ).

Answer 45 · 2017-06-08T09:47:59.000Z

@sriedel Unless you are monkeypatching the old gem. Switching to the new one should be just a Gemfile modification.
Remember that the new gem don't include the integrations by default.

Answer 46 · 2017-06-08T10:03:50.000Z

@sriedel I'm suspecting you are looking at the forked and outdated https://github.com/seuros/state_machine? If so then have a look at https://github.com/state-machines/state_machines which is recent, stable and released as a gem thanks to @seuros. While it has been split up to several gems it's pretty much just needs a Gemfile change IIRC.