uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4
Date Wed, 08 Jan 2014 21:15:35 GMT
This is somehow related to a late commit to trunk done here:


The source.zip picked up the "old" value, while the tag got the new one.

This can't happen, except as follows:

1) the release:prepare builds from the copy in the checkout on disk (which could
be missing a late-arriving update).
2) the release:prepare therefore builds in /target a version of source-release
without the late-arriving update.
3) the release:prepare "tags" the source, but this is done by telling SVN to
'copy' the trunk to the tag; data is not transmitted from the checkout to the
tag.  This means, the tag has the late-arriving update).
4) the release:perform checkouts the tag into .../target/checkout, and builds
that.  This creates new artifacts in  .../target/checkout/target, including a
new source-release.zip.  This will match the svn tag.

The error occurred when the source-release.zip was posted to p.a.o for
examination: it was uploaded (manually) from
.../target/uima-ducc-1.0.0-source-release.zip, instead of

This uploaded the version of source-release which was missing the late-arriving

So, the moral of this story is 2-fold: don't change the trunk while someone's
doing releasing :-), and when uploading release candidate artifacts, be sure to
pick them from .../target/checkout/target/... not .../target.

I'll add a note about this to our web-site pages release and checklist-release.

On 1/8/2014 3:03 PM, Marshall Schor wrote:
> After correcting for line ending differences, I find a few places the SVN tag
> and the source zip don't compare:
> svn tag: ducc-applications.tex: line 318 -
>    MyAppDir=$PWD \
>    MyInputDir=$PWD/Books \
>    MyOutputDir=$PWD/Books.processed \
> source zip:
>    MyAppDir=. \
>    MyInputDir=$MyAppDir/Books \
>    MyOutputDir=$MyAppDir/Books.processed \
> plus 2 more instances in this file.
> It would seem impossible, if normal release / build approaches were done, for
> these to differ.  Can anyone explain how this happened?
> -Marshall

View raw message