On 03.04.2013 12:14, Jörg Schaible wrote: > Hi Sebb, > > sebb wrote: > >> On 3 April 2013 06:56, Mladen Turk <mt...@apache.org> wrote: >> >>> On 04/03/2013 02:21 AM, sebb wrote: >>> >>>> On 2 April 2013 16:25, Mladen Turk <mt...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
