search

geekq / workflow

Ruby finite-state-machine-inspired API for modeling workflow
MIT License
1.74k stars 207 forks source link

Future of Workflow gem #177

Closed duffyjp closed 5 years ago

duffyjp commented 8 years ago

@geekq hasn't posted to this project for over a year. I wonder if it's time to pass the torch?

The most active fork I've found is here: https://github.com/cthiel/workflow-orchestrator, at 65 commits ahead of geekq.

There is also AASM, from which workflow is based, still under active development: https://github.com/aasm/aasm

emclab commented 8 years ago

seems abandoned. nobody is taking any questions. aasm is much more active.

geekq commented 8 years ago

workflow ist not abandoned - just very stable ;-)

Will update travis CI configuration for Rails 4.2 and 5.0 beta in the next days and check for compatibility.

Also will have a look at workflow-orchestrator, thanks for the research @duffyjp !

dgmike commented 7 years ago

Well, we should migrate to the version of @duffyjp ?

I found a bug on my MacOs but I don't know if I should migrate.

duffyjp commented 7 years ago

@dgmike For what it's worth, I have a large production app happily using workflow, but for a new app I used AASM. I actually built that app with workflow and converted it to AASM. The specific reason was that I couldn't get conditional events to work in workflow.

Example:

  event :delete,  transitions_to: :deleted,  if: :deletable?

In aasm you have to be much more explicit in your workflow states, 

    event :delete do
      transitions from: :available, to: :deleted, if: :deletable?
    end

It works as advertised though.

geekq commented 7 years ago

I've updated dependencies and ensured workflow and tests work with the newest Ruby 2.3.1 and all Rails versions before 5.0. https://travis-ci.org/geekq/workflow/builds/151611814

Integration with the changed ActiveRecord 5.0 causes some problems though. I'm going through the Rails changelog at the moment.

svoop commented 6 years ago

@geekq

Long time, no commits. I very much like workflow, however, it becomes increasingly difficult to stick to it. As it stands, your punchline "like acts as state machine (aasm), but way better" doesn't really hold anymore. I might switch to "aasm" after all, but before that, a question: It's absolutely normal to loose interest in further maintaining a gem, we've all been there I guess. If that's the case, how about asking around whether somebody else would be willing to pick up the torch?

(I know, "feel free to fork", but that's exactly the problem: Too many forks out there already. In order to keep workflow afloat, a canonical release via Rubygems is a must – or it will slowly fragment into oblivion like many others have before.)

geekq commented 6 years ago

Hi Sven,

for me, the bad sign is not the number of commits or time since the last commit, but missing support for Rails 5 integration. For previous Rails versions (I have got a couple of legacy applications) workflow still perfectly works for me.

Contrary to my original plans, I have not found time to refactor for Rails 5.*. Sorry!

If you can provide, or know a well maintained fork with Rails 5 support, please tell me! I'll link it from the top of the README. "Too many forks" is never a problem in my opinion (just example - https://github.com/ansible/ansible/network). But the lack of a fork, where not just problems of one user solved by monkey patching, but problems solved in a generic way (for allmost all users) and in well-maintainable manner (separation of concerns, modularisations), can be a problem.

svoop commented 6 years ago

Hello Vladimir,

fair point there on missing support. Since my current pet projects are very domain specific (aviation), I don't even count on such a thing, but I know it can be frustrating. However, you have to admit that the current README doesn't really sound like a request for support. A clear "co-maintainer wanted" note might help. Or not. At least, it's worth a try.

Some people have patched beyond your last commit as per the insight-network chart. Maybe just quick workarounds, then again, one of the forkers might be motivated to work on a more future-proof approach. Why not dropping some of them a quick note asking?

voltechs commented 5 years ago

(I know, "feel free to fork", but that's exactly the problem: Too many forks out there already. In order to keep workflow afloat, a canonical release via Rubygems is a must – or it will slowly fragment into oblivion like many others have before.) (@svoop)

I so agree with this! Let someone help shoulder the burden. You can remain the BDFL, but leverage the work the OS Community has done and has to offer.

Some people have patched beyond your last commit as per the insight-network chart. Maybe just quick workarounds, then again, one of the forkers might be motivated to work on a more future-proof approach. Why not dropping some of them a quick note asking? (@svoop)

Again, I support this! I've just opened a PR in which I've brought the testing framework up-to-date (ish). What do you say we start getting some of this work merged in, @geekq? Looks like lot's of people are eager to help. Don't let this popular project stagnate (yes, you're correct that lack of commits does not indicate abandonment, and in-fact can indicate stability, however technology inevitably marches on, and we'd be wise to keep up with it). As @svoop has advocated for, a canonical release would be excellent. There is a wealth of improvements sitting in your bank of PRs, waiting for your capitalization :)

Thanks again for the great gem/project, and for your contributions to the community.

~ Dale

geekq commented 5 years ago

Hi Dale,

thanks for your support, and for the motivation! ;-) I'm currently playing on a branch with the changes from the Modernize pull request https://github.com/geekq/workflow/pull/209 which looks most promising.

It contains Travis CI and gem configuration update, switches to the minitest etc.

But I'm still looking for a sustainable solution regarding Rails integration. My experience supporting different Rails versions is best described in

So my plan is to use the new major release Workflow 2.0.0 to also extract the ActiveRecord support into a separate library. This will decouple the release life cycle and maintenance pace for the workflow gem from the Rails gems. You never know, what Rails 6.0 (released in some weeks) and 7.0 (development starts end of January) will bring. ;-) User will just need to reference 2 libraries.

Also looking for the best naming for the new library/gem like

Will continue tomorrow...

Cheers

voltechs commented 5 years ago

No problem, @geekq :)

Yea I read the blog post about "moving on from" rails, it's a bit dated, but I lived through the same timeframe/evolution. The author makes some great points. Rails has certainly improved significantly since that post, and I believe the community is finding it's independent voice from Rails. Rails of course is, and will continue to be a very big player in the Ruby community, but it's learning to play nicer too. Anyhow, I digress.

I definitely think making a rails-independent gem is a worthwhile cause, and then having an ActiveRecord adapter gem for it as well. You're using the right naming convention too, with - being for extensions etc. I will say however, that I don't believe appending a version to the name of the gem is a good idea. RubyGems/Bundler goes to great lengths to provide a robust dependency-tree management capability, and I'd encourage leveraging that before offending the name of your project/gem/library with a version number. Most of the time it doesn't take much to get a gem working across a range of versions.

As you can see from that PR, it's building successfully across a range of activerecord and ruby versions. This reduces the cognitive load of those who wish to utilize your library/gem.

You could continue to release non-breaking changes (despite potential refactors) to v1.x for continued support up through ActiveRecord 3.0 (or whatever is reasonable) and then start a v2.x track that only supports current versions (that'd be Ruby 2.3+ and ActiveRecord 5.0+ I believe. (I'm personally supporting ActiveRecord 4.2 in a number of my gems until I can get my employer upgraded to 5.x, but boy am I looking forward to dropping support for 4.2).

Also, correct me if I'm wrong, but a user would only need to reference one library—workflow-activerecord would have workflow as a runtime dependency, so that'd be included automatically as well 🙂.

Looking forward to seeing where you take it all. I think I can speak for anyone engaged here: let us know if and how we can help!

geekq commented 5 years ago

So, here is the plan for versioning / Rails integration:

Progress so far:

~ Vladimir (@geekQ)

voltechs commented 5 years ago

@geekq Very nice.

Might I recommend Railtie for "magic" integration?

module Workflow
  class Railtie < Rails::Railtie
    initializer 'workflow.init' do |_app|
      # logger.debug "workflow.init" # if you want...
      ::ActiveSupport.on_load(:active_record) do
        # do your include/extend/prepending here
      end
    end
  end
end

And then in your workflow/active_record.rb file (in the root of your -active_record gem:

require 'workflow/active_record/railtie' if defined?(Rails::Railtie)

This seems to be the fairly common/least-invasive pattern I've seen/used in my gems.

geekq commented 5 years ago

See also the development in https://github.com/geekq/workflow-activerecord/issues

geekq commented 5 years ago

Merged modernize branch, since extract-ActiveRecord-support is almost ready. Renamed the default branch to develop to make it purpose clear.

geekq commented 5 years ago

Workflow 2.0 released!

Please try it out with your application! If it is a Rails application, please use https://rubygems.org/gems/workflow-activerecord/versions/4.1.2 Instructions, how to use are at https://github.com/geekq/workflow-activerecord#workflow-activerecord

Note for contributors: looks like github closed all the pull requests after I changes the default branch on 2019-01-12. Please check the new refactored workflow 2.0, complementing workflow-activerecord and recreate your pull request if needed.

geekq commented 5 years ago

Please report any bugs as a new issue for the relevant of both libraries: