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 >
