[Perl-workflow-devel] Development Cycle, Roadmap and Release Process

[Jonas B. N. <jo...@gm...>]

Hello,

Before writing this stuff I though I would run it by the list for  
review. These are my thoughts on the development cycle, roadmap and  
release process for the Workflow project in general.

As stated on the homepage of the project we are running under the  
following directives:

- Extensibility
- Stability

I am lacking a third directive, but I hope it will present itself at  
some point.

The reason to have the 3 directives is a technique I learned during  
education, when getting to a cross road of sort, a dicussion which  
require conclusion or an obstacle, the directives can help make the  
right decision. The reason why I have chosen these two directives are:

1. Extensibility, Workflow is a framework, it should be extensible  
for the developer/user utilizing it so it can be used to solve the  
user/developers particular problem without having to patch the core  
modules.

2. Stability, Workflow is in production in several places and when  
Chris handed it over to me as maintainer I looked at it as already  
finished, but it still has a lot of potential for improvement etc.  
and "code is never really done" to quote a book I am reading. - but  
Workflow is actually put to use and is not a toy system, so we need  
stability in order for the project to keep afloat.

I am for the release early, release often paradigm, but this is an  
open source project and it is not the primary work for most of us, so  
we make releases when there is something to release, so in order to  
keep releases frequent (and the project alive) we keep releases small.

As for development and releases, I divide this into two parts:

1. Bug/Documentation fixes, resulting in maintenance releases
2. New features or feature enhancements resulting in regular releases

The regular releases will be planned, not scheduled, but planned - in  
that sense they come from the ROADMAP and can be identified as tasks  
in the sf.net project system.

The ROADMAP is an outline of where we want to go, only the firstmost  
topic is being worked for the forthcoming release, but we can  
reprioritize, parallelize etc. as long as we have the resources and  
the will to do so.

A developer (or several) will be assigned to the ROADMAP scheduled  
activities (tasks) and it is released when it is done, until the  
release several maintenance releases might be made (based on branches  
from the last release point).

I am very much interested in development is also focused on unit- 
tests, since the release process is dependent on the test suite  
passing prior to release, but it is expected that developers does not  
break the test-suite with out notificed the rest of the project  
members. I regard the test-suite as a safeguard to keep stability,  
however tests contain bugs aswell or as in our case is not covering  
the code completely.

This brings me to the other part of the development efforts aimed at  
Quality Assurance.

I attempted to get the coverage for the project improved, this is an  
ongoing process, but the goal is stability, so we can develop more  
freely, using the test-suite as a tool to ensure we have no unforseen  
problems. We want to break tests in that sense we want the code to  
evolve, but we want to KNOW when we break it so we can address this.

The current ROADMAP looks like the following:

Development:

- Implement dynamically loading of workflows
- Implement versioning of workflows
...There are several feature requests in the system and there is not  
need for me to list them here...

QA:

- Improve test coverage

So that was sort of what I have in mind and things are up for  
discussion, I will get back with a preliminary draft of my ideas on  
how the bug handling process.

Looking forward to hearing your thoughts on the topic,

jonasbn