Marshall Schor wrote: > Michael Baessler wrote: >> Marshall Schor wrote: >> >>> I've just updated the version numbers to 2.2.2-incubating-SNAPSHOT. >>> >>> There's a new script, "changeVersion.xml", which is an "ant" build >>> script, that will change the version in most of the places where it >>> needs changing. For those it doesn't do, it echoes a message saying to >>> remember to manually change the files. >>> >>> This script takes as input another file, versions.properties. This file >>> has the "previous" and "new" values of the version, in various forms, >>> and the value of the "snapshot" suffix. >>> >>> To do a new change, add some stanzas on the front - I think we should >>> leave the values already there as a kind of "history" of the version >>> changes. >>> >> Sounds good. Thanks! >> Please update the "How to do a release" web page with that new >> information. >> http://incubator.apache.org/uima/release#Preparing%20The%20Sourcecode%20For%20The%20Release >> >> >>> ----------- >>> For the release process I think it goes like this: >>> >>> Change the version - removing "-SNAPSHOT", in this case (the version is >>> currently set to 2.2.2-SNAPSHOT) >>> Create a tag per instructions on >>> http://incubator.apache.org/uima/release#Building%20The%20Release%20Candidate >>> >>> >>> Build from the tag, sign things, run the RAT report, and put the >>> candidate artifacts somewhere on people.apache.org, in a private place >>> (this is not yet documented on our Release page, I think). >>> >> right this should be added... >> >>> Iterate as needed, changing in the trunk (which is versioned at the >>> release version now, without SNAPSHOT), re-tagging, etc. >>> etc. >>> >>> After the release is completed, change the version, incrementing to the >>> next guessed release number, and adding -SNAPSHOT. >>> ----------- >>> The signing works as follows (I'm guessing here, so please correct :-) ) >>> >>> For maven deployment, you use the mvn -DsignArtifacts=true source:jar >>> deploy in the uimaj pom directory. This has the side effect of >>> rebuilding and rerunning the tests for all the artifacts, and as another >>> side effect, it generates the checksums (md5 and sha1) for the uploaded >>> artifacts. >>> >>> The artifacts being uploaded to apache.org/dist/incubator/uima consist >>> of the binary assembly, the source assembly, and the eclipse update >>> site. mvn assembly:assembly executed in the uimaj-distr project creates >>> these, and adds the checksums as well. >>> The script signRelease.sh is being updated to (a) no longer generate >>> checksums (they were in the wrong format, and the assembly:assembly step >>> already is generated them (in the right format), and (b) gpg sign not >>> only the artifacts for the source/binary releases, but also those for >>> the eclipse update site. >>> The uimaj-distr/target has the source and binary results, and the >>> uimaj-eclipse-update-site/target/eclipse-update-site has the eclipse >>> update site result. >>> >>> >> Sounds correct :-) >> >> So does this mean that we are back at a working build? > I think so. >> If we are, I will >> try to build a release to check if all these steps works as expected. >> > Great! Thanks. >> I also added some comments to issue UIMA-684 "update webiste with "how >> to do a release" to track the open items. >> > Good. I've updated our website, and just now did an svn -update on > people.a.o. Please take a look when you have a chance. >> -- Michael >> >> >> > The build works fine for me again (except for some minor issues of the docbook build, that only occurs when building the first time). I also successfully verified the artifact signing with signRelease.sh.
The website looks good but we still have two open TODOs. If these are fixed I think we can officially link the page from our website. Building the from the source distribution does not work. I opened a Jira issue for that UIMA-835. -- Michael
