camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [VOTE] Release Apache Camel 2.10.6
Date Tue, 02 Jul 2013 18:34:54 GMT

On Jul 2, 2013, at 2:10 PM, Christian Müller <christian.mueller@gmail.com> wrote:

> I'm ok with cutting a new release if it solves an issue with
> camel-xmlsecurity, CXF or whatever.
> 
> I'm a bit concerned about the following minor updates:
> servicemix-specs-version from 1.9.0 to 2.2.0

This is needed to not end up with confusion in Karaf 2.3 (which uses specs version 2.2). 
It doesn't cause problems on Karaf 2.2, but fixes things on 2.3.

> xmlbeans-bundle-version from 2.5.0_2 to 2.6.0_2
> In general, we only have micro (bug fix) dependency updates in our
> maintenance releases. Did you checked whether this both dependency updates
> are fully backwards compatible?

Yes.  That said, the xmlbeans one could be rolled back if wanted.   I think 2.5.0_2 is being
pulled in by activemq 5.7 so it's still there.   The main issue again is, if using the obr,
you could get different versions depending on if you start the camel components first or if
you start CXF first.   CXF would pull in 2.6.     In general, I prefer a more predictable
scenario.   That said, in this case, 2.5.0 will likely not break anything in CXF like the
old xmlsec version would.

> And referring to the Camel 2.10.6 tag, you are right. It is the same with
> the Camel 2.10.5 tag which I mentioned in the VOTE thread [1]. This is
> because we use the Maven release plugin with the configuration
> pushChanges=false (this is the recommended configuration). If somebody
> commit a change to the GIT repository after the Maven release plugin tagged
> my local copy but before I pushed it to the central repository, I have to
> do a rebase which leads to this. Using pushChanges=true will solve this,
> but if we have to redo the release, we have to remove the tag in the
> "central" repository (not really central - I know). Because this is a bad
> practice in a distributed repository, we shouldn't use this configuration.
> Any idea what else we can do?

Just make sure you push as quickly as possible after the build.   At most, the difference
should be an hour or two.  It's not something you can start the build and go to bed and push
the tags and stuff the next day.     That and better communication ahead of time (including
time for people to respond and object) about when the builds will occur. 

Dan


> 
> [1]
> http://camel.465427.n5.nabble.com/VOTE-Release-Apache-Camel-2-10-5-td5734607.html
> 
> Best,
> Christian
> -----------------
> 
> Software Integration Specialist
> 
> Apache Camel committer: https://camel.apache.org/team
> V.P. Apache Camel: https://www.apache.org/foundation/
> Apache Member: https://www.apache.org/foundation/members.html
> 
> https://www.linkedin.com/pub/christian-mueller/11/551/642
> 
> 
> On Tue, Jul 2, 2013 at 4:06 AM, Daniel Kulp <dkulp@apache.org> wrote:
> 
>> I think I'm -1 on this (not a veto, just a vote).
>> 
>> If you look at the history of the 2.10.x branch:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=camel.git;a=shortlog;h=refs/heads/camel-2.10.x
>> 
>> It LOOKS like my changes should be in the release since all the changes
>> were done before the maven-release-plugin things.  However, they aren't
>> part of the release.  That kind of screws up the history logs and such
>> which bugs me a bit.
>> 
>> Many of the duplicate things I fixed today fix other issues, although it
>> could be argued some of those issues are in CXF/WSS4J.  For example,
>> without the xmlsec version update, if you install the camel-xmlsecurity
>> feature prior to installing CXF/WSS4J, then a bunch of the ws-security
>> things in CXF won't work.
>> 
>> Dan
>> 
>> 
>> On Jul 1, 2013, at 6:01 PM, Christian Müller <christian.mueller@gmail.com>
>> wrote:
>> 
>>> To address CVE-2013-2160 [1], we have a new bug fix release candidate
>>> apache-camel-2.10.6 ready. This bug fix was necessary, because the Apache
>>> Camel feature descriptor for Apache Karaf was still using Apache CXF
>>> 2.6.6.1. This release comes with 8 issues resolved [2]. You can find the
>>> release notes here [3].
>>> 
>>> Please find the staging repo here:
>>> https://repository.apache.org/content/repositories/orgapachecamel-095/
>>> 
>>> The tarballs are here
>>> 
>> https://repository.apache.org/content/repositories/orgapachecamel-095/org/apache/camel/apache-camel/2.10.6/
>>> 
>>> Tag:
>>> 
>> https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=b788c083b81ee73f8eec01240c46fc49db1b9f89
>>> 
>>> Please review, help out with testing and vote to approve this release
>>> binary. This is our first release which uses the new Confluence version
>> to
>>> create the HTML manual. The PDF manual is not created anymore.
>>> Please mention what you tested to prevent duplicate work. Your vote
>> counts!
>>> 
>>> [ ] +1 Release the binary as Apache Camel 2.10.6
>>> [ ] -1 Veto the release (provide specific comments)
>>> Vote is open for at least 72 hours.
>>> 
>>> [1]
>> https://cxf.apache.org/security-advisories.data/CVE-2013-2160.txt.asc
>>> [2]
>>> 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%20%222.10.6%22
>>> [3]
>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311211&version=12324024
>>> 
>>> Thanks in advance,
>>> Christian
>>> -----------------
>>> 
>>> Software Integration Specialist
>>> 
>>> Apache Camel committer: https://camel.apache.org/team
>>> V.P. Apache Camel: https://www.apache.org/foundation/
>>> Apache Member: https://www.apache.org/foundation/members.html
>>> 
>>> https://www.linkedin.com/pub/christian-mueller/11/551/642
>> 
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>> 
>> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message