You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2008/02/29 03:17:10 UTC
Release process with respect to updating the version, tagging, and
signing
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.
-----------
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).
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.
-Marshall
-----------
Does this sound right?
-Marshall
Re: Release process with respect to updating the version, tagging,
and signing
Posted by Michael Baessler <mb...@michael-baessler.de>.
> Building the from the source distribution does not work. I opened a Jira
> issue for that UIMA-835.
>
UIMA-835 fixed and verified. Source distribution build successful.
-- Michael
Re: Release process with respect to updating the version, tagging,
and signing
Posted by Michael Baessler <mb...@michael-baessler.de>.
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
Re: Release process with respect to updating the version, tagging,
and signing
Posted by Marshall Schor <ms...@schor.com>.
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
>
>
>
Re: Release process with respect to updating the version, tagging,
and signing
Posted by Michael Baessler <mb...@michael-baessler.de>.
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? If we are, I will
try to build a release to check if all these steps works as expected.
I also added some comments to issue UIMA-684 "update webiste with "how
to do a release" to track the open items.
-- Michael