jBPM3 should release lock-step with jPDL4

[thomas.diesler]

Folks,

looking at the road map, I see

jBPM jPDL 3.2.4 (01-Sep-2008)
jPDL 4.0 alpha1 (01-Aug-2008)
jPDL 4.0 alpha2 (11-Sep-2008)

First, I think we should have a consistent naming scheme (i.e. either we use the jBPM prefix or not)

Second, it is important that the releases go lock-step with respect to the API. Only if the functionality offered through the API has an actual implementation in both code bases we can be sure that it is the API that we want.

For details of the process see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=138168

Therefore I propose for jPDL4 a release cycle that aligns with jBPM3. Faster than eight weeks is very hard to manage anyway given the documentation and test coverage that is required.

[tom.baeyens]

I think we should have a consistent naming scheme (i.e. either we use the jBPM prefix or not)

good point. let's take "jPDL {version}"

Therefore I propose for jPDL4 a release cycle that aligns with jBPM3. Faster than eight weeks is very hard to manage anyway given the documentation and test coverage that is required.

the problem is that i need enough coverage in jPDL 4 to know that the basic public API starts off in the right direction. some of the advanced concepts will have their impact on the basic part of the api.

i wanted to reflect with this release schedule that in my estimation, jPDL 4.0.alpha2 has enough coverage so that we can be confident that the basic parts of the api remain stable.

[thomas.diesler]

I aligned the even alpha releases with jBPM3. Another important point (apart from inter-project dependencies) is management of the workload for the whole team.

For any given eight week period you have N projects to work on and you can schedule your workload such that everything gets done by a well defined date.

[camunda]

Another important point (apart from inter-project dependencies) is management of the workload for the whole team.

Hi Thomas, but this isn't the case for the contributers. For me personally I have some backlog of stuff I want to commit but cannot plan in advance when I can do it, since it is "a hobby" and has to fit in spare times coming here and there (but are not planned).

Does this schedule mean, that if I have spare time in a code freeze I cannot commit anything? Or do you branch somehow so development on head can go further on?

Cheers
Bernd

[thomas.diesler]

At code freeze we branch to a QA branch - you can always commit to trunk,