Just a quick question, can we lock the branch when doing the release? If so , it can avoid this kind of issue.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Wednesday, July 3, 2013 at 3:59 AM, Christian Müller wrote: > Hi Dan! > > [snip] > 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. > [snap] > > After re-thinking about it, I think it's however possible (and not a so bad > practice) to delete a tag in a distributed source code management > repository as we use it with a quasi central Git repository at get-wip-us. > As I will go and cancel this vote to include your changes and cut a new > one, I have to delete the camel-2.10.6 tag too. Let's change the Maven > release plugin configuration to pushChanges=true and see whether it works > better for us (I think so meanwhile. > > 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 8:34 PM, Daniel Kulp <dk...@apache.org > (mailto:dk...@apache.org)> wrote: > > > > > On Jul 2, 2013, at 2:10 PM, Christian Müller <christian.muel...@gmail.com > > (mailto:christian.muel...@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 <dk...@apache.org > > > (mailto:dk...@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.muel...@gmail.com (mailto:christian.muel...@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 > > > > dk...@apache.org - http://dankulp.com/blog > > > > Talend Community Coder - http://coders.talend.com > > > > > > > > > > > -- > > Daniel Kulp > > dk...@apache.org - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com >
