-
Notifications
You must be signed in to change notification settings - Fork 510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is this gem no longer maintained? EOM #310
Comments
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. |
someone should just fork it and take it over |
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. |
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. |
Hope this is not another 'CanCan' situation. |
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. |
Rails 4.1 here and still working well. Indeed, we need a fork on this.. |
It works with 4.0 but in 4.1 tests explode. Didn't have time to look into it yet. |
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 ? |
+1. @obrie ? |
+1 |
👍 i would love to have a fork of this gem being still maintained ! |
👍 |
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"? |
Yeah , sure. |
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. |
such a pity, I've had to switch to AASM |
@dongennl how was the migration from this gem to AASM? |
@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! |
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. |
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. |
Yes it does. All patches are applied. |
It may be time to simply take @seuros' fork and publish it as a new gem... |
I need to fix little bug for AR 4.2 first, i will do that next week. sorry. |
@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. |
Have an idea about mainaining #331 |
AFAIK yes. if not, i will fix it. |
The Spree project relies heavily on state_machine, and we are going to release our own fork for now: 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. |
@seuros if you haven't already are you planning to do a stable gem release? |
Did you see this work : https://github.com/state-machines/ ? I'm using the activemodel integration in a personal project without any issue ! :) |
Oh nice no I hadn't @alouanemed will have to try that out. |
We had switched to https://github.com/aasm/aasm, but that looks a little more compatible. |
👍 |
No stable gem release to depend on... Looks like it would work if I didn't have to point to the git repo. |
@JDutil , i can release an alpha, there are still few bugs with AR42 integration and internalization. |
Hmm might have been other commits not in there: 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. |
So theres state-machines/state_machines-activerecord and spree-contrib/state_machine now. |
spree-contrib/state_machine is going away we will be using state-machines/state_machines-activerecord |
@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. |
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 :) ). |
@sriedel Unless you are monkeypatching the old gem. Switching to the new one should be just a Gemfile modification. |
@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. |
…hines-activerecord resolves pluginaweek/state_machine#310
No description provided.
The text was updated successfully, but these errors were encountered: