Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKjo4PNv+ONY6NkK6-tCBwqBrG17ctE2tKWvoh5hVdApRb+5ig@mail.gmail.com>
References: 
 <CAGT3RRP4LAD_7Cw8p6L7Qh-8b-KZAFdUYDFnGWpTEfiKObW9dw@mail.gmail.com>
	<CAKjo4PNv+ONY6NkK6-tCBwqBrG17ctE2tKWvoh5hVdApRb+5ig@mail.gmail.com>
Date: Fri, 5 Jun 2015 11:46:40 +0200
Message-ID: 
 <CAGT3RROccweyrT0=is5o8BoYZjnjke4jMSDnpd1-9cnnFBVnDw@mail.gmail.com>
Subject: Re: [VOTE] Apache Felix Dependency Manager Release Candidate R4
From: Pierre De Rop <pierre.derop@gmail.com>
To: "dev@felix.apache.org" <dev@felix.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3439183f6fd90517c22b67

--047d7b3439183f6fd90517c22b67
Content-Type: text/plain; charset=UTF-8

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 <bdekruijff@gmail.com>
wrote:

> On Thu, Jun 4, 2015 at 11:17 PM, Pierre De Rop <pierre.derop@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
>

--047d7b3439183f6fd90517c22b67--