The 'Workflow' Perl module implements a standalone workflow system. It aims to be simple but flexible and therefore powerful. Each piece of the 'Workflow' system has a direct and easily stated job, and hopefully you will find that you can put the pieces together to create very useful systems.
Read the documentation ('perldoc Workflow') for a more detailed introduction, sample usage, interactions with your applications, and more.
More documentation will be written as a part of this site some time in the future
'Workflow' is normally referred to as 'Workflow' the name perl-workflow was picked when moving project activities to SourceForge, where the name was occupied by a Java project, however the distribution of the system on CPAN is called 'Workflow' and on this site the system will be referred to as 'Workflow' and perl-workflow interchangably.
'Workflow' was originally initiated and developed by Chris Winters.
'Workflow' is currently maintained by Jonas B. Nielsen and a large number of active users, contributors and patchers, if you are interested in participating please refer to the Main Page#Workflow Development section
Goal of Workflow
The goal of 'Workflow' is to be a complete standalone workflow system, where the user can implement generic workflows using this framework.
The project in it's current form are running under these project directives in order to define the scope of the project
Brief history of Workflow
- 11th. of October 2004 - Initial release to CPAN (0.10)
- 7th. of July 2006 - Jonas B. Nielsen takes over maintenance from Chris Winters
- 19th. of September 2006 - Project set up at SourceForge
Copyright (c) 2003 Chris Winters and Arvato Direct. All rights reserved.
Copyright (c) 2004, 2005, 2006 Chris Winters. All rights reserved.
This software is available under the Artistic license and is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
- Chris Winters, original author.
The following folks have also helped out:
- Danny Sadinoff, patches to give better control of initial state and history records for workflow
- Thomas Erskine, for patch adding new accessors and fixing several bugs
- Ivan Paponov, for patch implementing action groups, See Changes file, 0.32_7
- Robert Stockdale, for patch implementing dynamic names for conditions, See Changes file, 0.32_6
- Jim Brandt, for patch to Workflow::Config::XML. See Changes file, 0.27 and 0.30
- Alexander Klink, for: patches resulting in 0.23, 0.24 and 0.25
- Michael Bell, for patch resulting in 0.22
- Martin Bartosch, for bug reporting and giving the solution not even using a patch (0.19 to 0.20) and a patch resulting in 0.21
- Randal Schwartz, for testing 0.18 and swiftly giving feedback (0.18 to 0.19)
- Chris Brown, for a patch to Workflow::Config::Perl (0.17 to 0.18)
- Dietmar Hanisch - Provided most of the good ideas for the module and an excellent example of everyday use.
- Tom Moertel gave Chris the idea for being able to attach event listeners (observers) to the process.
- Michael Roberts graciously released the 'Workflow' namespace on CPAN; check out his Workflow toolkit at http://www.vivtek.com/wftk.html.
- Michael Schwern barked via RT about a dependency problem and CPAN naming issue.
- Jim Smith - Contributed patches (being able to subclass Workflow::Factory) and good ideas.
- Martin Winkler - Pointed out a bug and a few other items.
Bug Reporting and Feature Requests
We currently utilize a central database for bug reports, tasks, patch contributions and feature requests. Name the Request Tracker (RT) installation for CPAN (see also Main Page#Resources).
So if you want to contact the developers this be done either via Request Tracker (RT)
Or via email
"bug-test-timer at rt.cpan.org"
A list of currently known issues can be seen via examining the RT queue for Workflow.
A list of wanted features are listed in the Main Page#Road Map
The goal of 'Workflow' is to be a complete standalone workflow system, where the user can implement generic workflows using the framework. The current maintainer have setup these project directives in order to define the scope of the project.
'Workflow' is written in Perl and provides a framework for building workflows in Perl.
The code base is hosted in a Subversion repository on SourceForge.
% svn co https://perl-workflow.svn.sourceforge.net/svnroot/perl-workflow perl-workflow
We utilize branches extensively. This holds the following benefits:
- Non-disruptive behavior in relation to parallel tasks or ongoing work
- Ease of management, branches can simply be discarded if necessary
- Focus on a single task in a branch
- Our development speed is not the fastest, so a branch can be as long-lived as necessary, see also the point above
Example: Branching trunk to some branch for spiking/prototyping etc.
% svn cp \
Example: Branching for an RT issue task/fix:
% svn cp \
Example: Branching for test/evaluation of a patch:
% svn cp \
% svn cp \
See also Version Numbers
The main version number for 'Workflow' is isolated in the file VERSION in the root of the distribution directory, this file is increased accordingly when a new release is prepared. See Releases below.
All modules and scripts carry a version number, that is maintained manually. We update this when functionality changes. Whitespace changes, POD additions does not necessarily require an version update, but this is left to the developers discretion, but please update the version of bugs are fixed, functionality is changed or added since the version can be used to identify differing behavior at load time.
The different tasks making up the 'Workflow' project have been divided into several sub-projects/responsibilities (see: also []):
- Quality Assurance
This sub division has been made in order to categorize tasks #patches
'Workflow' is open source so patches are most welcome, we do not give any guarantees that your patch will be accepted in it's original for, if accepted at all. We use the primary projects directives and there for attempt to keep the code base within these limits, but in general the project is very open and we have a record of accepting most patches.
If you want to send us a patch, please use one of the following ways:
Patches are more than welcome, patches should adhere to the strategy described in #Version Numbers.
Patches are preferred accompanied by documentation and tests. If this is not the case, please make an appropriate entry in the Changes file, which in-depth describes the purpose/motivation of the patch and what it influences.
To create a patch using the diff command, use the following format:
% diff -u file.new file.org > file.patch
Using subversion to generate a patch:
% svn diff -u file.new > file.patch
We aim for release early release often.
A historic view of the releases of Workflow
- 1.34 - public release
- 1.33 - public release
- 1.33_8 - development release
- 1.33_7 - development release
- 1.33_6 - development release
- 1.33_5 - development release
- 1.33_4 - development release
- 1.33_3 - development release
- 1.33_2 - development release
- 1.32 - public release
- 0.32_8 - development release
- 0.32_7 - development release
- 0.32_6 - development release
- 0.32_5 - development release
- 0.32_4 - development release
- 0.32_3 - development release
- 0.32_2 - development release
- 0.32_1 - development release
- 0.31 - public release (download)
- 0.30 - public release
- 0.28 - public release
- 0.27 - public release
- 0.26 - public release
- 0.25 - public release
- 0.24 - public release
- 0.23 - public release
- 0.22 - public release
- 0.21 - public release
- 0.20 - public release
- 0.19 - public release
- 0.17 - public release
- 0.16 - public release
- 0.15 - public release
- 0.10 - public release
In order to make a release the following steps should be taken. This process will hopefully be automated at some point, perhaps using release from CPAN, which supports both CPAN and SourceForge.
1. Close the changes file
Insert proper version number in Changes file
Insert date in Changes file
2. Clean the directory and prepare the for the build
% ./Build realclean
% perl Build.PL
3. Make sure all tests pass
% export TEST_POD=1
% ./Build test
4. Update MANIFEST file
% ./Build manifest
5. Build the distribution tar.gz file
% ./Build dist
6. Check that this distribution is ok
% ./Build distcheck
7. Upload to appropriate distribution channels like PAUSE/CPAN and Sourceforge
You are welcome to get involved, this can be done in many ways, here we list a few:
- Send a patch (See: [])
- [the mailinglist] and discuss the roadmap of the project
- We have plenty of tasks and things to do, which are not development related and so if you are interested in helping out, please let us know
- Use 'Workflow' and send us your feedback
- Release Maintainer: jonasbn
- Project admin: jonasbn
- Webmaster: jonasbn
- FreeBSD distribution: Sergei Vyshenski
Plenty of people are not on this list and have contributed, please refer to the Acknowledgements section.
This is the current Road Map for Workflow:
- Implement dynamically loading of workflows
- Implement versioning of workflows
Ongoing tasks that need not be part of the Road Map, but should taken into account for every Distribution Release
- Improve and update documentation
- Improve and update test suite
- Improve and update test coverage
Ongoing tasks that require releases and immediate actions
- Bug fixes
The Workflow project is currently hosted with SourceForge.net and is listed on Ohloh.
The code is kept under revision control using Subversion:
The Workflow project has a mailing list for discussion of issues and development. The list is low-traffic.
- Commit log <http://rss.gmane.org/messages/excerpts/gmane.comp.lang.perl.modules.workflow.scm>
- Ohloh news <https://www.ohloh.net/p/perl-Workflow/messages.rss>
- CPAN testers reports <http://cpantesters.perl.org/show/Workflow.rss>
- AnnoCPAN: Annotated CPAN documentation
- CPAN Ratings
- Search CPAN