pluginaweek / state_machine

Adds support for creating state machines for attributes on any Ruby class
http://www.pluginaweek.org
MIT License
3.74k stars 507 forks source link

Is this gem no longer maintained? EOM #310

Open cscairns opened 10 years ago

thijsc commented 10 years ago

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.

cscairns commented 10 years ago

someone should just fork it and take it over

gtd commented 10 years ago

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.

seuros commented 10 years ago

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.

simonmd commented 10 years ago

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

cscairns commented 10 years ago

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.

waldofe commented 10 years ago

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

firedev commented 10 years ago

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

jeffrfinn commented 10 years ago

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 ?

mothra commented 10 years ago

+1. @obrie ?

mensfeld commented 10 years ago

+1

nicolasblanco commented 10 years ago

:+1: i would love to have a fork of this gem being still maintained !

pchaganti commented 10 years ago

:+1:

gtd commented 10 years ago

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"?

jeremywadsack commented 10 years ago

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

seuros commented 10 years ago

Yeah , sure.

gtd commented 10 years ago

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.

dongennl commented 10 years ago

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

cscairns commented 10 years ago

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

dongennl commented 10 years ago

@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!

lunks commented 10 years ago

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.

nicolasblanco commented 10 years ago

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.

rusterholz commented 10 years ago

+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.

seuros commented 10 years ago

Yes it does. All patches are applied.

andrewvc commented 10 years ago

@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.

rusterholz commented 9 years ago

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

seuros commented 9 years ago

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

andrewvc commented 9 years ago

@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.

gemtainers commented 9 years ago

Have an idea about mainaining #331

rusterholz commented 9 years ago

@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!

seuros commented 9 years ago

AFAIK yes. if not, i will fix it.

jesperronn commented 9 years ago

@seuros I tried your master branch, and https://github.com/pluginaweek/state_machine/issues/314 still exist.

I still get uninitialized state on the model.new

JDutil commented 9 years ago

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.

JDutil commented 9 years ago

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

alouanemed commented 9 years ago

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

JDutil commented 9 years ago

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

jeremywadsack commented 9 years ago

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

alouanemed commented 9 years ago

:+1:

JDutil commented 9 years ago

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

seuros commented 9 years ago

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

JDutil commented 9 years ago

@seuros that would be good after incorporating some of the fixes we needed: https://github.com/pluginaweek/state_machine/pull/333

seuros commented 9 years ago

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

JDutil commented 9 years ago

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.

kakoni commented 9 years ago

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

JDutil commented 9 years ago

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

neumachen commented 9 years ago

@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.

sriedel commented 7 years ago

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 :) ).

seuros commented 7 years ago

@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.

espen commented 7 years ago

@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.