Re: Reproducible build and prelease information

Hi Russ,

And also thanks Jesse, for your message.


>> [in the Git tag]
>> VERSION_EXTRA	= prerelease
> 
>> [in the tarball]
>> VERSION_EXTRA	=
> 
>> For the next releases, I then suggest to adapt the release process to
>> manually remove "prerelease" in the same commit as the one that modifies
>> the FAQ to reflect the new version.  (This is usually the latest commit
>> before the release.)  And re-adding "prerelease" in the subsequent
>> commit that also modifies Makefile.global.in to bump the version number.
> 
> Ugh, sorry.  Yeah, that's probably the right fix.  It's a bit tedious, but
> I can't think of a better way to do it.

I also did not come to a smarter way to do that in the release process. 
Well, removing and re-adding a word just takes a few seconds; I can cope 
with it, especially when it's done only once or twice a year :)



>> In order to make the build reproducible, I suggest an improvement for
>> people building from Git (the date used will be the one of the latest
>> commit instead of the current date).  Otherwise, it won't change from
>> the current behaviour.
> 
>> if [ x"$extra" = x"prerelease" ]; then
>>      # Ensure a reproducible build when the source code has not changed.
>>      LAST_COMMIT_DATE=$(git log -1 --pretty=%cd --date=format:%Y%m%d
>>      2>/dev/null | tr -d '-')
> 
> I don't think you need the tr.

Yes!  Thanks for the remark.  It was a vestige of a previous command 
without the --date=format argument.



> The one drawback to this is that it doesn't notice if there are
> uncommitted changes to the local tree.  In this case, I don't think it's
> worth handling that

Yes, having uncommitted changes is not the use case to deal with.  It 
might be improved, though, if someone really cares for that.



> but I note it just because some tools like
> setuptools_scm that do something equivalent do use a different version in
> that case.

I've just had a look at that tool, which indeed handles several cases 
including the one of a dirty working repository.



> I'd go with this approach, though.  The other option would be to use git
> describe, which is more accurate than our historic practice of using the
> date (which I think may go all the way back to CVS), but I don't feel that
> inspired to switch.  (And git describe doesn't work on the main branch.)

Committed.
I'll have a look at the snapshots generated these next days to make sure 
they have the right date.

-- 
Julien ÉLIE

« – Il l'aura voulu.
   – Tu crois vraiment ? » (Astérix)
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers