These are the joint meeting notes of Tom and Thomas from the September meeting in Turnhout.

jBPM needs predictable and reliable release cycles. We reduce the project deliverables to one jBPM3 plus one jBPM4 release every eight weeks. The release cycles of jBPM3 and jBPM4 are to be aligned. For the foreseeable future it is not necessary to split up the various jBPM4 modules in separate projects (i.e. jPDL4 and PVM should be merged to jBPM4). The next three release dates will be 1-Nov-2008, 1-Jan-2009, 1-Mar-2009

With every release cycle there is stuff to do and people who do it. Folks pick up stuff according to their skill set, experience and component ownership. Releases are achieved together as a team.

On 1-Nov-2008, there will be a jBPM 3.3.0 GA release and a jBPM 4.0.0 Alpha 1 release. The whole team will work to make those two releases happen and everyone is invited to take their share of responsibility. The biggest bulk of the work for everyone in the next release cycle will be done for jBPM 3.3.0 GA. After that release, jBPM 3 will be put in maintenance mode.

The scope of jBPM 4.0.0 Alpha 1 is about setting up the infrastructure around what is present now in the jBPM 4 code base. Getting the different components runtime engine, runtime installation, container deployment, designer and console all hooked up together properly. The focus of the whole team can shift to jBPM 4 development with the next release cycle starting 1-Nov-2008. The scope is limited so that everyone in the team has enough time left to pick up issues from jBPM 3.3.0.

One of the future goals is that processes can be modelled by a BPMN editor. Thomas says, it is therefore necessary that jBPM4 recognizes and supports the concepts from BPMN. Here we could not reach an agreement and it remains to be discussed to what extend and how BPMN support will look like. An API+CTS is developed that covers these concepts. Thomas is going to lead the API+CTS effort.

To replace jBPM3 at one point in the future, it is necessary to establish the replacement criteria. One of the requirements is support of the valid feature set from jBPM3. Another is support for a meaningful subset of BPMN concepts. A catalogue of features and supported concepts that defines the replacement criteria. A certain piece of functionality is there if there is a CTS test case and comprehensive documentation for it.

There are a number of open issues in the jBPM 3.3.0.GA and jBPM 4.0.0.Alpha1 releases. Please have a look at which issues you can take and synchronize with Thomas in case of questions as he'll be the main driver behind this first release cycle.

Further jBPM 4 development will be a clear team effort with a lot of room for open discussions, debates and proposals. All concepts and even the basics of what's there in jBPM 4 will be looked at before they make their way into the API. The goal is that jBPM 4 will have the right fundamentals. All this will be done as a collaborative process - what counts is correctness. As we have 5 very capable people in the team, this exchanging of ideas will result into a much better quality of jBPM 4.

In jBPM 4 development, Tom will act as a lead and be a decisions maker in circumstances when no consensus can be reached. But more important, we both realize the necessity of reaching consensus on most (if not all) of the decisions to be taken.

To kickstart the jBPM 4 development, there will be a team meeting with the whole jBPM team. This meeting should be end October or early November. Then with the whole team we'll discuss and reach agreements on the jBPM 4 approach, roadmap, components, and strategy.

The first target of the jBPM 4 functional scope is jBPM 3. In the meeting we'll agree upon how BPMN and workflow patterns can be supported and define the priorities and approach for this. If the spirit of our team meeting is anything close to our current meeting in Turnhout, then we are very much convinced that whatever we'll come up with in jBPM 4, it will be an awsome BPM product which will exceed the sum of the individual contributions.