[GitHub] camel pull request #2349: Allow applications to control whether to stop rout...
Github user oscerd closed the pull request at: https://github.com/apache/camel/pull/2349 ---
Re: Getting ready for Camel 2.22 Release with SB2 support
Yes, it is, but some bundles are available already -- Andrea Cosentino -- Apache Camel PMC Member Apache Karaf Committer Apache Servicemix PMC Member Email: ancosen1...@yahoo.com Twitter: @oscerd2 Github: oscerd On Thursday, May 24, 2018, 7:35:01 AM GMT+2, Claus Ibsen wrote: On Wed, May 23, 2018 at 10:17 AM, Andrea Cosentino wrote: > We need to take care of Karaf features too. Actually we have some > misalignments between bundles and JARs > Is the SMX team working on this, such as a new set of bundles to be released. > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix PMC Member > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > > > > On Wednesday, May 23, 2018, 9:08:38 AM GMT+2, Claus Ibsen > wrote: > > > > > > Hi > > I want to let us get started early on preparing for the upcoming and > anticipated release of Apache Camel 2.22, that has support for Spring > Boot 2. > > We have this release scheduled for next month (June), and it would be > good to start closing down on issues and finish up new implementations > and components etc. > > And then get bugs fixed, tests passing and build stabilised on the CI > infrastructure as well. > > The CI builds on master looks good at this moment > https://builds.apache.org/job/Camel/job/master/ > > The JIRA roadmap has 58 to-do tickets > https://issues.apache.org/jira/issues/?jql=project+%3D+CAMEL+AND+fixVersion+%3D+2.22.0+AND+statusCategory+%3D+new > > Which likely is too many to get resolved before the release. So I will > create a Camel 2.22.1 and 2.23.0 version where tickets can be > re-assigned as target versions. > > > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Getting ready for Camel 2.22 Release with SB2 support
Hi There is a few new component that needs documentation in the src/main/docs folder, such as camel-rx2 and camel-reactor On Wed, May 23, 2018 at 9:08 AM, Claus Ibsen wrote: > Hi > > I want to let us get started early on preparing for the upcoming and > anticipated release of Apache Camel 2.22, that has support for Spring > Boot 2. > > We have this release scheduled for next month (June), and it would be > good to start closing down on issues and finish up new implementations > and components etc. > > And then get bugs fixed, tests passing and build stabilised on the CI > infrastructure as well. > > The CI builds on master looks good at this moment > https://builds.apache.org/job/Camel/job/master/ > > The JIRA roadmap has 58 to-do tickets > https://issues.apache.org/jira/issues/?jql=project+%3D+CAMEL+AND+fixVersion+%3D+2.22.0+AND+statusCategory+%3D+new > > Which likely is too many to get resolved before the release. So I will > create a Camel 2.22.1 and 2.23.0 version where tickets can be > re-assigned as target versions. > > > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Getting ready for Camel 2.22 Release with SB2 support
On Wed, May 23, 2018 at 10:17 AM, Andrea Cosentino wrote: > We need to take care of Karaf features too. Actually we have some > misalignments between bundles and JARs > Is the SMX team working on this, such as a new set of bundles to be released. > -- > Andrea Cosentino > -- > Apache Camel PMC Member > Apache Karaf Committer > Apache Servicemix PMC Member > Email: ancosen1...@yahoo.com > Twitter: @oscerd2 > Github: oscerd > > > > > > > On Wednesday, May 23, 2018, 9:08:38 AM GMT+2, Claus Ibsen > wrote: > > > > > > Hi > > I want to let us get started early on preparing for the upcoming and > anticipated release of Apache Camel 2.22, that has support for Spring > Boot 2. > > We have this release scheduled for next month (June), and it would be > good to start closing down on issues and finish up new implementations > and components etc. > > And then get bugs fixed, tests passing and build stabilised on the CI > infrastructure as well. > > The CI builds on master looks good at this moment > https://builds.apache.org/job/Camel/job/master/ > > The JIRA roadmap has 58 to-do tickets > https://issues.apache.org/jira/issues/?jql=project+%3D+CAMEL+AND+fixVersion+%3D+2.22.0+AND+statusCategory+%3D+new > > Which likely is too many to get resolved before the release. So I will > create a Camel 2.22.1 and 2.23.0 version where tickets can be > re-assigned as target versions. > > > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: testcontainers
Of course, any image available on docker hub (or other registries) can be used. --- Luca Burgazzoli On Wed, May 23, 2018 at 11:16 PM, Alex Dettinger wrote: > Hi Luca, > > +1 as you demonstrated the use to test starters. > > I already faced a situation where a custom docker image would have helped > in testing a regular camel component. > Would it be in the scope of camel-testcontainers ? I mean building a custom > image, pushing it to docker hub and use that for route level tests of a > regular component ? > > Alex > > > > On Wed, May 23, 2018 at 9:39 AM, Luca Burgazzoli > wrote: > >> Like: >> >> https://github.com/lburgazzoli/apache-camel/blob/ >> CAMEL-12485/platforms/spring-boot/components-starter/camel- >> consul-starter/pom.xml#L67-L128 >> >> >> --- >> Luca Burgazzoli >> >> >> On Wed, May 23, 2018 at 9:38 AM, Luca Burgazzoli >> wrote: >> > It can be done by checking the presence of the docker socket file or >> > DOCKER_HOST env var >> > >> > --- >> > Luca Burgazzoli >> > >> > >> > On Wed, May 23, 2018 at 8:56 AM, Willem Jiang >> wrote: >> >> Hi Luca, >> >> >> >> I guess you mean the maven profile. Please correct me if I'm wrong. >> >> Currently I need to user -Pdocker to enable the docker related test in >> my >> >> project. >> >> >> >> I'm not sure if we enable the profile by default if there is a docker >> >> command in the box. >> >> >> >> >> >> >> >> Willem Jiang >> >> >> >> Blog: http://willemjiang.blogspot.com (English) >> >> http://jnn.iteye.com (Chinese) >> >> Twitter: willemjiang >> >> Weibo: 姜宁willem >> >> >> >> On Wed, May 23, 2018 at 2:22 PM, Luca Burgazzoli > > >> >> wrote: >> >> >> >>> Hi Zoran, >> >>> >> >>> On Tue, May 22, 2018 at 10:03 PM, Zoran Regvart >> wrote: >> >>> > Hi Luca, >> >>> > sounds like a good idea, would be really good if we transitioned (no >> >>> > need for a big bang), to JUnit 5 then we could use conditional logic >> >>> > to skip those tests if for instance docker is not available. >> >>> > >> >>> > I would also consider marking those as integration tests so they are >> >>> > run only if we want them to be run, or in environments that we know >> >>> > they'll run without issues. >> >>> > >> >>> >> >>> As first iteration I'd use profiles, junit 5 is not exatly as easy as >> >>> junit 4 is. >> >>> >> >>> > zoran >> >>> > >> >>> > On Tue, May 22, 2018 at 5:35 PM, Luca Burgazzoli < >> lburgazz...@gmail.com> >> >>> wrote: >> >>> >> Hi all, >> >>> >> >> >>> >> I've been using testcontainers [1] for a while and I found it useful >> >>> >> to test against non java services such as consul, etcd and so on so >> >>> >> I'd like to create a camel-testcontainers "component" that includes >> >>> >> some facilities like a dedicated test support that take care of >> >>> >> starting/stopping containers. >> >>> >> >> >>> >> Any objection/suggestion ? >> >>> >> >> >>> >> Regards, >> >>> >> Luca >> >>> >> >> >>> >> [1] https://www.testcontainers.org/ >> >>> >> >> >>> >> >> >>> >> --- >> >>> >> Luca Burgazzoli >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Zoran Regvart >> >>> >>
Re: testcontainers
Hi Luca, +1 as you demonstrated the use to test starters. I already faced a situation where a custom docker image would have helped in testing a regular camel component. Would it be in the scope of camel-testcontainers ? I mean building a custom image, pushing it to docker hub and use that for route level tests of a regular component ? Alex On Wed, May 23, 2018 at 9:39 AM, Luca Burgazzoli wrote: > Like: > > https://github.com/lburgazzoli/apache-camel/blob/ > CAMEL-12485/platforms/spring-boot/components-starter/camel- > consul-starter/pom.xml#L67-L128 > > > --- > Luca Burgazzoli > > > On Wed, May 23, 2018 at 9:38 AM, Luca Burgazzoli > wrote: > > It can be done by checking the presence of the docker socket file or > > DOCKER_HOST env var > > > > --- > > Luca Burgazzoli > > > > > > On Wed, May 23, 2018 at 8:56 AM, Willem Jiang > wrote: > >> Hi Luca, > >> > >> I guess you mean the maven profile. Please correct me if I'm wrong. > >> Currently I need to user -Pdocker to enable the docker related test in > my > >> project. > >> > >> I'm not sure if we enable the profile by default if there is a docker > >> command in the box. > >> > >> > >> > >> Willem Jiang > >> > >> Blog: http://willemjiang.blogspot.com (English) > >> http://jnn.iteye.com (Chinese) > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> > >> On Wed, May 23, 2018 at 2:22 PM, Luca Burgazzoli > > >> wrote: > >> > >>> Hi Zoran, > >>> > >>> On Tue, May 22, 2018 at 10:03 PM, Zoran Regvart > wrote: > >>> > Hi Luca, > >>> > sounds like a good idea, would be really good if we transitioned (no > >>> > need for a big bang), to JUnit 5 then we could use conditional logic > >>> > to skip those tests if for instance docker is not available. > >>> > > >>> > I would also consider marking those as integration tests so they are > >>> > run only if we want them to be run, or in environments that we know > >>> > they'll run without issues. > >>> > > >>> > >>> As first iteration I'd use profiles, junit 5 is not exatly as easy as > >>> junit 4 is. > >>> > >>> > zoran > >>> > > >>> > On Tue, May 22, 2018 at 5:35 PM, Luca Burgazzoli < > lburgazz...@gmail.com> > >>> wrote: > >>> >> Hi all, > >>> >> > >>> >> I've been using testcontainers [1] for a while and I found it useful > >>> >> to test against non java services such as consul, etcd and so on so > >>> >> I'd like to create a camel-testcontainers "component" that includes > >>> >> some facilities like a dedicated test support that take care of > >>> >> starting/stopping containers. > >>> >> > >>> >> Any objection/suggestion ? > >>> >> > >>> >> Regards, > >>> >> Luca > >>> >> > >>> >> [1] https://www.testcontainers.org/ > >>> >> > >>> >> > >>> >> --- > >>> >> Luca Burgazzoli > >>> > > >>> > > >>> > > >>> > -- > >>> > Zoran Regvart > >>> >
[GitHub] camel pull request #2349: Allow applications to control whether to stop rout...
GitHub user maxfortun opened a pull request: https://github.com/apache/camel/pull/2349 Allow applications to control whether to stop routes on dns lookup failure Allow applications to control whether to stop routes on dns lookup failure You can merge this pull request into a Git repository by running: $ git pull https://github.com/maxfortun/camel master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/2349.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2349 commit 25dce9452c765312c5147001d0cd84dd845605b8 Author: Max Fortun Date: 2018-05-22T21:19:39Z Allow exceptions to be thrown so that route control could be configured on application level. commit 5e8ba4a4fc6f7dac89d5a9874286c1861e9a3b05 Author: Max Fortun Date: 2018-05-22T21:21:54Z Allow exceptions to be thrown so that route control could be configured on application level. ---
Re: JUnit5, was: testcontainers
Hi David, yes we can wait for that and the Surefire/Failsafe release that includes it. I think we can also add org.junit.platform:junit-platform-surefire-provider:1.2.0 dependency to the existing Surefire/Failsafe plugin configurations. As far as I understand that issue is tracking the incorporation of the existing codebase from JUnit5 into Surefire. zoran On Wed, May 23, 2018 at 10:15 AM, David Karlsen wrote: > Would you have to await for > https://issues.apache.org/jira/browse/SUREFIRE-1330 to be merged to get > surefire support? > > Den ons. 23. mai 2018 kl. 10:08 skrev Zoran Regvart : > >> Hi, >> on the testcontainers thread I mentioned that we can switch to JUnit5. >> I've attended a talk by Sam Brannen at the local JUG. I think it was a >> variant of the talk[1] he gave at SpringOne 2017. >> >> The key takeaway for me was that JUnit5 is forward and backward >> compatible, so you can run the same tests written with JUnit4 >> annotations on JUnit5, but you can also run JUnit5 tests on JUnit4, if >> for some reason that would make sense in a particular case. >> >> What I understood is that we could upgrade to JUnit5 by simply >> upgrading the surefire/failsafe Maven plugins and adding the >> junit-vintage-engine dependency but only to a module that has mixed >> JUnit4 and JUnit5 tests[2]. The only issue is limited @Rule support. >> >> Now on to the benefits, I think it makes much sense to move over to >> JUnit5 for the conditional test execution[3], better categorization of >> tests via tags[4] and the much better extension model[5]. >> >> I propose that we schedule this for the one release after the pending >> one (so in 2.23), and that we add camel-test-jupiter component that >> would help developers write nicer tests for their integrations with >> support for dependency injection for example[6]. >> >> zoran >> >> [1] https://www.youtube.com/watch?v=h0Idcz71Aog >> [2] >> https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 >> [3] >> https://junit.org/junit5/docs/current/user-guide/#writing-tests-conditional-execution >> [4] >> https://junit.org/junit5/docs/current/user-guide/#writing-tests-tagging-and-filtering >> [5] https://junit.org/junit5/docs/current/user-guide/#extensions >> [6] >> https://junit.org/junit5/docs/current/user-guide/#writing-tests-dependency-injection >> -- >> Zoran Regvart >> > > > -- > -- > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen -- Zoran Regvart
Re: Getting ready for Camel 2.22 Release with SB2 support
We need to take care of Karaf features too. Actually we have some misalignments between bundles and JARs -- Andrea Cosentino -- Apache Camel PMC Member Apache Karaf Committer Apache Servicemix PMC Member Email: ancosen1...@yahoo.com Twitter: @oscerd2 Github: oscerd On Wednesday, May 23, 2018, 9:08:38 AM GMT+2, Claus Ibsen wrote: Hi I want to let us get started early on preparing for the upcoming and anticipated release of Apache Camel 2.22, that has support for Spring Boot 2. We have this release scheduled for next month (June), and it would be good to start closing down on issues and finish up new implementations and components etc. And then get bugs fixed, tests passing and build stabilised on the CI infrastructure as well. The CI builds on master looks good at this moment https://builds.apache.org/job/Camel/job/master/ The JIRA roadmap has 58 to-do tickets https://issues.apache.org/jira/issues/?jql=project+%3D+CAMEL+AND+fixVersion+%3D+2.22.0+AND+statusCategory+%3D+new Which likely is too many to get resolved before the release. So I will create a Camel 2.22.1 and 2.23.0 version where tickets can be re-assigned as target versions. -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: JUnit5, was: testcontainers
Would you have to await for https://issues.apache.org/jira/browse/SUREFIRE-1330 to be merged to get surefire support? Den ons. 23. mai 2018 kl. 10:08 skrev Zoran Regvart : > Hi, > on the testcontainers thread I mentioned that we can switch to JUnit5. > I've attended a talk by Sam Brannen at the local JUG. I think it was a > variant of the talk[1] he gave at SpringOne 2017. > > The key takeaway for me was that JUnit5 is forward and backward > compatible, so you can run the same tests written with JUnit4 > annotations on JUnit5, but you can also run JUnit5 tests on JUnit4, if > for some reason that would make sense in a particular case. > > What I understood is that we could upgrade to JUnit5 by simply > upgrading the surefire/failsafe Maven plugins and adding the > junit-vintage-engine dependency but only to a module that has mixed > JUnit4 and JUnit5 tests[2]. The only issue is limited @Rule support. > > Now on to the benefits, I think it makes much sense to move over to > JUnit5 for the conditional test execution[3], better categorization of > tests via tags[4] and the much better extension model[5]. > > I propose that we schedule this for the one release after the pending > one (so in 2.23), and that we add camel-test-jupiter component that > would help developers write nicer tests for their integrations with > support for dependency injection for example[6]. > > zoran > > [1] https://www.youtube.com/watch?v=h0Idcz71Aog > [2] > https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 > [3] > https://junit.org/junit5/docs/current/user-guide/#writing-tests-conditional-execution > [4] > https://junit.org/junit5/docs/current/user-guide/#writing-tests-tagging-and-filtering > [5] https://junit.org/junit5/docs/current/user-guide/#extensions > [6] > https://junit.org/junit5/docs/current/user-guide/#writing-tests-dependency-injection > -- > Zoran Regvart > -- -- David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
JUnit5, was: testcontainers
Hi, on the testcontainers thread I mentioned that we can switch to JUnit5. I've attended a talk by Sam Brannen at the local JUG. I think it was a variant of the talk[1] he gave at SpringOne 2017. The key takeaway for me was that JUnit5 is forward and backward compatible, so you can run the same tests written with JUnit4 annotations on JUnit5, but you can also run JUnit5 tests on JUnit4, if for some reason that would make sense in a particular case. What I understood is that we could upgrade to JUnit5 by simply upgrading the surefire/failsafe Maven plugins and adding the junit-vintage-engine dependency but only to a module that has mixed JUnit4 and JUnit5 tests[2]. The only issue is limited @Rule support. Now on to the benefits, I think it makes much sense to move over to JUnit5 for the conditional test execution[3], better categorization of tests via tags[4] and the much better extension model[5]. I propose that we schedule this for the one release after the pending one (so in 2.23), and that we add camel-test-jupiter component that would help developers write nicer tests for their integrations with support for dependency injection for example[6]. zoran [1] https://www.youtube.com/watch?v=h0Idcz71Aog [2] https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 [3] https://junit.org/junit5/docs/current/user-guide/#writing-tests-conditional-execution [4] https://junit.org/junit5/docs/current/user-guide/#writing-tests-tagging-and-filtering [5] https://junit.org/junit5/docs/current/user-guide/#extensions [6] https://junit.org/junit5/docs/current/user-guide/#writing-tests-dependency-injection -- Zoran Regvart
Re: testcontainers
Like: https://github.com/lburgazzoli/apache-camel/blob/CAMEL-12485/platforms/spring-boot/components-starter/camel-consul-starter/pom.xml#L67-L128 --- Luca Burgazzoli On Wed, May 23, 2018 at 9:38 AM, Luca Burgazzoli wrote: > It can be done by checking the presence of the docker socket file or > DOCKER_HOST env var > > --- > Luca Burgazzoli > > > On Wed, May 23, 2018 at 8:56 AM, Willem Jiang wrote: >> Hi Luca, >> >> I guess you mean the maven profile. Please correct me if I'm wrong. >> Currently I need to user -Pdocker to enable the docker related test in my >> project. >> >> I'm not sure if we enable the profile by default if there is a docker >> command in the box. >> >> >> >> Willem Jiang >> >> Blog: http://willemjiang.blogspot.com (English) >> http://jnn.iteye.com (Chinese) >> Twitter: willemjiang >> Weibo: 姜宁willem >> >> On Wed, May 23, 2018 at 2:22 PM, Luca Burgazzoli >> wrote: >> >>> Hi Zoran, >>> >>> On Tue, May 22, 2018 at 10:03 PM, Zoran Regvart wrote: >>> > Hi Luca, >>> > sounds like a good idea, would be really good if we transitioned (no >>> > need for a big bang), to JUnit 5 then we could use conditional logic >>> > to skip those tests if for instance docker is not available. >>> > >>> > I would also consider marking those as integration tests so they are >>> > run only if we want them to be run, or in environments that we know >>> > they'll run without issues. >>> > >>> >>> As first iteration I'd use profiles, junit 5 is not exatly as easy as >>> junit 4 is. >>> >>> > zoran >>> > >>> > On Tue, May 22, 2018 at 5:35 PM, Luca Burgazzoli >>> wrote: >>> >> Hi all, >>> >> >>> >> I've been using testcontainers [1] for a while and I found it useful >>> >> to test against non java services such as consul, etcd and so on so >>> >> I'd like to create a camel-testcontainers "component" that includes >>> >> some facilities like a dedicated test support that take care of >>> >> starting/stopping containers. >>> >> >>> >> Any objection/suggestion ? >>> >> >>> >> Regards, >>> >> Luca >>> >> >>> >> [1] https://www.testcontainers.org/ >>> >> >>> >> >>> >> --- >>> >> Luca Burgazzoli >>> > >>> > >>> > >>> > -- >>> > Zoran Regvart >>>
Re: testcontainers
It can be done by checking the presence of the docker socket file or DOCKER_HOST env var --- Luca Burgazzoli On Wed, May 23, 2018 at 8:56 AM, Willem Jiang wrote: > Hi Luca, > > I guess you mean the maven profile. Please correct me if I'm wrong. > Currently I need to user -Pdocker to enable the docker related test in my > project. > > I'm not sure if we enable the profile by default if there is a docker > command in the box. > > > > Willem Jiang > > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, May 23, 2018 at 2:22 PM, Luca Burgazzoli > wrote: > >> Hi Zoran, >> >> On Tue, May 22, 2018 at 10:03 PM, Zoran Regvart wrote: >> > Hi Luca, >> > sounds like a good idea, would be really good if we transitioned (no >> > need for a big bang), to JUnit 5 then we could use conditional logic >> > to skip those tests if for instance docker is not available. >> > >> > I would also consider marking those as integration tests so they are >> > run only if we want them to be run, or in environments that we know >> > they'll run without issues. >> > >> >> As first iteration I'd use profiles, junit 5 is not exatly as easy as >> junit 4 is. >> >> > zoran >> > >> > On Tue, May 22, 2018 at 5:35 PM, Luca Burgazzoli >> wrote: >> >> Hi all, >> >> >> >> I've been using testcontainers [1] for a while and I found it useful >> >> to test against non java services such as consul, etcd and so on so >> >> I'd like to create a camel-testcontainers "component" that includes >> >> some facilities like a dedicated test support that take care of >> >> starting/stopping containers. >> >> >> >> Any objection/suggestion ? >> >> >> >> Regards, >> >> Luca >> >> >> >> [1] https://www.testcontainers.org/ >> >> >> >> >> >> --- >> >> Luca Burgazzoli >> > >> > >> > >> > -- >> > Zoran Regvart >>
Getting ready for Camel 2.22 Release with SB2 support
Hi I want to let us get started early on preparing for the upcoming and anticipated release of Apache Camel 2.22, that has support for Spring Boot 2. We have this release scheduled for next month (June), and it would be good to start closing down on issues and finish up new implementations and components etc. And then get bugs fixed, tests passing and build stabilised on the CI infrastructure as well. The CI builds on master looks good at this moment https://builds.apache.org/job/Camel/job/master/ The JIRA roadmap has 58 to-do tickets https://issues.apache.org/jira/issues/?jql=project+%3D+CAMEL+AND+fixVersion+%3D+2.22.0+AND+statusCategory+%3D+new Which likely is too many to get resolved before the release. So I will create a Camel 2.22.1 and 2.23.0 version where tickets can be re-assigned as target versions. -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
