yes, definitely. that is a waiste of time.
Thanks, but what about the separate releasecycles, just like with the GPD? Would make the contribution to the console much more interesting to others.
having a separate release cycle for the console is technically achievable (should not be too hard, i think)
but the console has much more API dependencies on core jBPM. so chances are that jBPM core updates will affect the console. and the relation between jbpm core and console will be much tighter then with the GPD, where only the jPDL XML schema is the interface.
I think we can take core versions into account in several ways. One thing that would be required then is to be able to retrieve a version of the core. Then some functionality will just be hidden if it ios not doable with the deployed core, or shown as 'upgrade to a later core if you want this functionality'.
Methods e.g. not implemented in the JbpmContext in certain versions of the core could be in a convenience class, backported if doable or partly backported and throwing an 'not implemented' exception.