On Fri, Jun 5, 2015 at 12:11 PM, Pierre De Rop <[email protected]> wrote: > So, is there an existing bnd directive that can disable the generation of > the Bnd-LastModified header ? this would then resolve the issue ? >
-removeheaders: Bnd-LastModified,Tool,Created-By grz Bram > thanks > /Pierre > > > On Fri, Jun 5, 2015 at 11:46 AM, Pierre De Rop <[email protected]> > wrote: > >> Hello Bram, >> >> First, thanks for your checks. no problem if I have to cancel this >> release. But before, can we discuss in order to clarify and confirm your -1: >> >> So, the latest version of the runtime bundle comes from the R2 release >> (runtime-4.0.1), and the runtime bundle has not been changed in R3, and R4. >> That is why the version is unchanged, but binary is different only because >> of the Bundle-LastModified headers are different, as you said (I just >> verified that): >> >> R3 -> Bnd-LastModified >> 1432232347449 >> R4 -> Bnd-LastModified >> 1433450664064 >> >> >> Let me explain with more details the process I'm using, and confirm if I'm >> reasoning write or wrong: >> >> So: >> >> 1) the baselining is performed against the cnf/releaserepo, where there is >> still the org.apache.felix.dependencymanager.runtime-4.0.0.jar version >> (R1). >> >> 2) The last time I modified the runtime was done in R2, that's why I did >> not modify the cnf/releaserepo where I still have the runtime 4.0.0 >> version. At the time I modified the runtime before release R2, then >> bndtools proposed me to increment the runtime version to 4.0.1 >> >> 3) Now, the next time I will modify the runtime, I will then update the >> releaserepo with runtime-4.0.1. So, then, when I will start to modify the >> runtime (before release R5 for example), then bndtools baselining will >> propose me to increment the version for the runtime bundle (to 4.0.2 for >> example). >> >> so, can you please confirm your -1 ? if your confirm -1, then can you >> please suggest how I should then make the next release ? >> >> Indeed, with Marcel, we previously agreed on the fact that a release >> should include all binary artifacts. >> So, I could systematically increment the bundle version even if the >> bundles have not been modified (by systematically updating the releaserepo >> with all previously released bundles), but then I think it would be weird >> to increment a bundle version even if it has not been changed ? >> >> thanks; >> /Pierre >> >> >> >> >> >> On Fri, Jun 5, 2015 at 10:29 AM, Bram de Kruijff <[email protected]> >> wrote: >> >>> On Thu, Jun 4, 2015 at 11:17 PM, Pierre De Rop <[email protected]> >>> wrote: >>> > Hello all, >>> > >>> > I would like to call for a vote on the Dependency Manager toplevel >>> release >>> > R4. >>> > >>> > We solved the following issues: >>> > >>> > Release Notes - Felix - Version org.apache.felix.dependencymanager-r4 >>> > >>> > ** Bug >>> > * [FELIX-4907] - ConfigurationDependency calls updated(null) when >>> > component is stopped. >>> > * [FELIX-4910] - ComponentExecutorFactory does not allow to return >>> null >>> > from getExecutorFor method. >>> > * [FELIX-4913] - DM Optional callbacks may sometimes be invoked >>> twice >>> > >>> > ** Improvement >>> > * [FELIX-4876] - DM Annotations bnd plugin compatibility with >>> Bndtools >>> > 2.4.1 / 3.0.0 versions >>> > * [FELIX-4877] - DM Annotations should detect service type using >>> more >>> > method signatures. >>> > >>> > You can use this UNIX script to download the release and verify the >>> > signatures: >>> > >>> > >>> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh >>> > >>> > Usage: >>> > sh check_staged_release.sh r4 /tmp/felix-staging >>> > >>> > This script, unlike the original Felix check_stage_release.sh, is >>> specific >>> > to the new Dependency Manager release process (see FELIX-4818) and will >>> > download staging from https://dist.apache.org/repos/dist/dev/felix >>> instead >>> > of http://repository.apache.org/content/repositories. >>> > >>> > To rebuild the DM binaries from the source, you can then refer to >>> > >>> https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/resources/src/README.src >>> > >>> > Please vote to approve this release: >>> > >>> > [ ] +1 Approve the release >>> > [ ] -1 Veto the release (please provide specific comments) >>> > >>> > This vote will be open for 72 hours. >>> > >>> >>> I am tempted to cast a (non-binding) -1... >>> >>> This r4 contains org.apache.felix.dependencymanager.runtime.jar that >>> differs from the one included in r3, but the Bundle-Version has not >>> been incremented from 4.0.1. >>> >>> This may be just because of differences in a manifest header (eg. >>> Bnd-Lastmodified?) or JDK, but you are still releasing multiple >>> versions of a binary artifact under the same version. >>> >>> IMHO this is undesirable and baselining should prevent this? >>> >>> Here's my quick check: >>> bramk@dabbert:~$ unzip -p >>> >>> /tmp/org.apache.felix.dependencymanager-r3-bin/org.apache.felix.dependencymanager.runtime.jar >>> META-INF/MANIFEST.MF | grep Bundle-Version >>> Bundle-Version: 4.0.1 >>> bramk@dabbert:~$ unzip -p >>> >>> /tmp/org.apache.felix.dependencymanager-r4-bin/org.apache.felix.dependencymanager.runtime.jar >>> META-INF/MANIFEST.MF | grep Bundle-Version >>> Bundle-Version: 4.0.1 >>> bramk@dabbert:~$ md5sum >>> >>> /tmp/org.apache.felix.dependencymanager-r3-bin/org.apache.felix.dependencymanager.runtime.jar >>> 62a78fb3f3f9df0892ac6afa9dea4d4e >>> >>> /tmp/org.apache.felix.dependencymanager-r3-bin/org.apache.felix.dependencymanager.runtime.jar >>> bramk@dabbert:~$ md5sum >>> >>> /tmp/org.apache.felix.dependencymanager-r4-bin/org.apache.felix.dependencymanager.runtime.jar >>> d4cef37afd1900140304a3ced4fc6bd3 >>> >>> /tmp/org.apache.felix.dependencymanager-r4-bin/org.apache.felix.dependencymanager.runtime.jar >>> >>> Best Regards, >>> Bram >>> >>> >>> >>> >>> >>> > Thank you; >>> > /Pierre >>> >> >>
