4 Replies Latest reply on Aug 7, 2006 10:27 AM by kukeltje

    jbpm webapp separate release cycle?

    kukeltje
    kukeltje Jul 26, 2006 6:51 PM

      I do not feel like spending time fixing things in the 3.1 webapp. I'm even more into making sure the webapp that currently is in the 3.2 branch works with a 3.1 core. This would give the opportunity to have separate release cycles just like the GPD has. It would probably attract more people to helping out. I think.

      Is it ok to 'won't fix' 3.1 webapp issues?

      • 2347 Views
      • Tags:
        • 1. Re: jbpm webapp separate release cycle?
          tom.baeyens
          tom.baeyens Jul 27, 2006 8:29 AM (in response to kukeltje)

          yes, definitely. that is a waiste of time.

            • Actions
          • 2. Re: jbpm webapp separate release cycle?
            kukeltje
            kukeltje Aug 7, 2006 8:48 AM (in response to kukeltje)

            Thanks, but what about the separate releasecycles, just like with the GPD? Would make the contribution to the console much more interesting to others.

              • Actions
            • 3. Re: jbpm webapp separate release cycle?
              tom.baeyens
              tom.baeyens Aug 7, 2006 9:08 AM (in response to kukeltje)

              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.

                • Actions
              • 4. Re: jbpm webapp separate release cycle?
                kukeltje
                kukeltje Aug 7, 2006 10:27 AM (in response to kukeltje)

                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.

                  • Actions