So, is there an existing bnd directive that can disable the generation of the Bnd-LastModified header ? this would then resolve the issue ?
thanks /Pierre On Fri, Jun 5, 2015 at 11:46 AM, Pierre De Rop <pierre.de...@gmail.com> 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 <bdekrui...@gmail.com> > wrote: > >> On Thu, Jun 4, 2015 at 11:17 PM, Pierre De Rop <pierre.de...@gmail.com> >> 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 >> > >
