Future of Workflow gem

[duffyjp]

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

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

[geekq]

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]

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]

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

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]

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

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]

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]

(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]

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
#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

• https://blog.makandra.com/2015/10/surviving-the-upgrade-pace-of-rails/
• http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html#not-a-good-citizen

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

• use workflow-activerecord5 until some bigger ActiveRecord changes arrive. Then create a new library
• vs. workflow-activerecord and provide branches, gem releases with exactly same version numbers
  as related ActiveRecord version

Will continue tomorrow...

Cheers

[voltechs]

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]

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

• workflow 1.2.0 (git branch stable-1-2-stable, gem version 1.2.0) to support old versions of Ruby and Rails LTS
• workflow 2.0 to become ActiveRecord independent (do refactoring on the git modernize, later use master branch for development; gem version 2.0.0)
• workflow-activerecord to implement ActiveRecord-integration for 4.2, 5.0 etc. On incompatible ActiveRecord API changes a branch like stable-4-2 supporting ActiveRecord 4.2, 5.0, 5.2 can be created.

Progress so far:

• add CC_TEST_REPORTER_ID to workflow build since nice badges are most important ;-)
  57% overall test coverage, but most important classes have 92%, 82%, 80%, 65%
  https://codeclimate.com/github/geekq/workflow/code

• create https://github.com/geekq/workflow-activerecord

• set up gemspec, Gemfile for workflow-activerecord

• set up CI for https://travis-ci.org/geekq/workflow-activerecord

• remove ActiveRecord integration (klass.send :include, Adapter::ActiveRecord) from workflow

• move ActiveRecord related tests to workflow-activerecord (test coverage will go down)

• add ActiveRecord integration (klass.send :include, Adapter::ActiveRecord)
  to workflow-activerecord. First draft using: (consider more magic later)

  include Workflow
  include WorkflowActiverecord
  

• Make extracted unit tests work in workflow-activerecord
  https://travis-ci.org/geekq/workflow-activerecord/jobs/476095275#L959

• add workflow-activerecord to codeclimate.org

• increase test coverage in the workflow by porting some tests back from
  workflow-activerecord and making them ActiveRecord independent

• Make workflow-activerecord work. Milestone: 2 libs in the newest version work
  as replacement for the old workflow

• Consider more magic - single include, single require for WorkflowActiveRecord

• Document workflow-activerecord

• Review/cleanup documentation for workflow

• Merge modernize branch to master

• ...

• publish (push) workflow 2.0.0 gem

• publish (push) workflow-activerecord 4.2.0 gem

~ Vladimir (@geekq)

[voltechs]

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

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

[geekq]

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

[geekq]

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]

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

• https://github.com/geekq/workflow/issues
• https://github.com/geekq/workflow-activerecord/issues