commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: [VOTE] Release Apache Commons Daemon 1.0.15
Date Wed, 03 Apr 2013 10:56:34 GMT
On 03.04.2013 12:14, Jörg Schaible wrote:
> Hi Sebb,
> 
> sebb wrote:
> 
>> On 3 April 2013 06:56, Mladen Turk <mturk@apache.org> wrote:
>>
>>> On 04/03/2013 02:21 AM, sebb wrote:
>>>
>>>> On 2 April 2013 16:25, Mladen Turk <mturk@apache.org> wrote:
>>>>
>>>>  On 04/02/2013 05:06 PM, Jörg Schaible wrote:
>>>>>
>>>>>  Mladen Turk wrote:
>>>>>>
>>>>>>  And BTW, build number can use multiple sources and its primary usage
>>>>>>> is with continuous integration. Our release version is build
number
>>>>>>> in this case.
>>>>>>>
>>>>>>>
>>>>>> We configured the build to take it from the current svn number to
>>>>>> reflect
>>>>>> the unique state of the repository. An entry like
>>>>>>
>>>>>> =========== %< =============
>>>>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>>>>> =========== %< =============
>>>>>>
>>>>>> will give the immediate impression, that something did go wrong with
>>>>>> the build. I'd rather drop the entry completely.
>>>>>>
>>>>>>
>>>>>>  I mean ASF is all about releasing sources. That's our primary
>>>>>>  product.
>>>>>
>>>>>
>>>> So building from the tag should be equivalent to building from the
>>>> source archive.
>>>>
>>>>
>>> Not necessary. Source distribution might have some pre-generated code.
>>> Many projects work like that and some even require manual handcraft from
>>> release manager.
>>>
>>>
>> It should still be possible to start from a workspace checkout of the tag,
>> rather than an unpack of the source archive.
>> The two should be identical except for the SVN files (and perhaps FOAF etc
>> that only belong in SVN).
> 
> This is the point: They cannot be identical, since the manifest contains 
> also stuff like build time, user name, JDK version (snipped):
> 
> ============== %< ================
> $ catmf commons-configuration-1.8.jar
> Created-By: Apache Maven Bundle Plugin
> Built-By: oheger
> Build-Jdk: 1.6.0_30
> Implementation-Build: tags/CONFIGURATION_1_8RC1@r1236874; 2012-01-27 2
>  1:39:19+0100
> Bnd-LastModified: 1327696771177
> ============== %< ================
> 
> Either we have such information and ensure that it is proper for a released 
> jar or we drop it and ensure that someone else can reproduce the *same* 
> artifacts (hashes are equal).
> 
> [snip]

Corect. Builds are typically not binary identical. In the C world
compilers often include the compile timestamp in the binaries. In the
Java world, if you bundle Javadoc in the builds they also contain
timestamps.

So it suffices if binaries are identical except for such expected minor
differences that do not influence functionality. It might be even seen
as a good thing if a binary contains an info about its origin as shown
above.

>From reading this thread my understanding is that the only *minor*
annoyance here is, that the current build procedure includes a metadata
(manifest) entry, that *looks* broken when building not from an svn
checkout but instead from an export or an extracted source archive. It
does not influence the source distribution nor the functionality of the
build.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message