Perfect. Then I'm happy with jbpm 3.3.x in the JBT3.2.x stream, and jbpm
3.4.x in the JBT3.3.x stream.
Make sure you update BOTH feature.xml / manifest.mf AND the accompanying
pom.xml files, too.
If you need a tool to check if you've forgotten any, use this:
cd ~/trunk/jbpm/; ~/trunk/build/util/checkPOMvsManifest.sh -v
(flags: -v = verbose, -q = quiet, -d = debug)
On 05/30/2011 01:15 PM, Koen Aers wrote:
The version contained in JBT 3.2.0.GA is 3.3.0 so it will indeed
only bleeding edge people who cannot "upgrade".
Op 30-mei-11, om 17:57 heeft Nick Boldt het volgende geschreven:
> As long as the version released in JBT 3.2.0.GA was not 3.4.0, then this
> change shouldn't impact any actual users (just maybe some QE folks
> who'll have to uninstall before they can "upgrade" from 3.4 to 3.3).
> If, however, the version of jBPM 3 jPDL released in 3.2.0.GA was 3.4.0,
> then you're screwed and can't backlevel.
> On 05/30/2011 07:10 AM, Koen Aers wrote:
>> With the resolution of JBIDE-8956 the version numbers of the jBPM 3 jPDL
>> plugin (org.jbpm.gd.jpdl) where unnecessarily bumped to 3.4.0 instead of
>> 3.3.1. JBIDE-8979 needed a different approach for trunk and for branch
>> as the problem did not exist in trunk. So Max and me decided to rollback
>> the change to 3.4.0 to 3.3.1 in branch rather than bumping the version
>> in trunk up to 3.5.0. This might create some fallout as rolling back a
>> version number is not a good thing. Is there anything else I need to do
>> to minimize this?
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> jbosstools-dev mailing list
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio