First of all: +1 (binding)
After reading up on the discussion, I do not agree that there is a problem that is big enough to cancel the release as Pierre proposes for the following reasons: 1) At Apache, we vote on the source code of the release. The binaries are there for convenience. I don’t see anything wrong with the sources other than the fact that adding that “-removeheaders” statement is probably a good idea. 2) There is nothing really wrong with the binaries either. Semantically they have the same version, because they have the same content. The only difference as far as I understand are these non-standard headers. Sure you can argue that that makes them different, but if you load the bundle into an OSGi framework, you end up with exactly the same code. Sure we can further optimise our release process, but this release complies with the procedure we have. A discussion about including unmodified binaries is something we should have separate from this release vote. Greetings, Marcel On 5 Jun 2015 at 12:36:02 , Pierre De Rop (pierre.de...@gmail.com) wrote: Thanks Bram, I'm cancelling this release. I like your suggestion that just consists in picking up the unmodified bundles from the releaserepo if not modified at all. That is safe and is making sense. I will just modify the gradle script in order to support a parameter that I will use to specify the list of bundles I want to release, and then other bundles will be simply picked up from the releaserepo. I will also update the release process in the README file. cheers /Pierre On Fri, Jun 5, 2015 at 12:18 PM, Bram de Kruijff <bdekrui...@gmail.com> wrote: > On Fri, Jun 5, 2015 at 12:11 PM, Pierre De Rop <pierre.de...@gmail.com> > 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 <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 > >>> > >> > >> >
