You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@uima.apache.org by sc...@apache.org on 2020/01/27 20:30:01 UTC
svn commit: r1873228 - in /uima/site/trunk/uima-website:
docs/checklist-release.html docs/release.html xdocs/checklist-release.xml
xdocs/release.xml
Author: schor
Date: Mon Jan 27 20:30:00 2020
New Revision: 1873228
URL: http://svn.apache.org/viewvc?rev=1873228&view=rev
Log:
no Jira update release and checklist-release - add git info, remove out-of-date and now wrong info.
Modified:
uima/site/trunk/uima-website/docs/checklist-release.html
uima/site/trunk/uima-website/docs/release.html
uima/site/trunk/uima-website/xdocs/checklist-release.xml
uima/site/trunk/uima-website/xdocs/release.xml
Modified: uima/site/trunk/uima-website/docs/checklist-release.html
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/docs/checklist-release.html?rev=1873228&r1=1873227&r2=1873228&view=diff
==============================================================================
--- uima/site/trunk/uima-website/docs/checklist-release.html (original)
+++ uima/site/trunk/uima-website/docs/checklist-release.html Mon Jan 27 20:30:00 2020
@@ -238,11 +238,12 @@
<li>Update the READMEs and RELEASE-NOTES.</li>
<li>Announce on the dev list that you're doing a release so others can get any changes in, and also
know not to be committing to trunk while you're in the middle of doing the release.</li>
- <li>Make a new build directory for this release, and svn checkout the trunk (svn "export" instead of checkout
+ <li>Make a new build directory for this release, and source control checkout the trunk or git clone the repo and switch to the branch (if needed).
+ (svn "export" instead of checkout
fails at a later commit step by the release plugin). This is so you can
preserve the build for later upload of selected artifacts to the distribution spot.
<p>
- If instead you are building from an existing checkout, do a svn update to be sure the workspace is up-to-date.
+ If instead you are building from an existing checkout, do a source control update to be sure the workspace is up-to-date.
</p>
</li>
<li>Purge your local maven repository of artifacts being built by running in the
@@ -255,7 +256,7 @@
So, instead, just go to the .m2 .../uima/ node and consider deleting that directory.</p>
</li>
<li>Do a full build with deploy of the (last) snapshot before release: mvn clean deploy -Papache-release</li>
- <li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/</li>
+ <li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/ or the git branch for the tag.</li>
<li>If retrying a release candidate, <code><b>close</b></code> (and <code><b>drop</b></code> as appropriate) any previous repository.apache.org staging repo</li>
<!--li>(If remerging a branch: Note- best to do these if possible at the root of aggregations,
outside of Eclipse, so svn "batching" can work - will be quite a bit fraster)
@@ -284,7 +285,7 @@
<code>mvn release:prepare -DdryRun -DautoVersionSubmodules</code>.
<li><code>mvn release:clean</code> to restore projects</li>
<li><code>mvn release:prepare [-DautoVersionSubmodules]</code>.
- Try to accept the default suggestions for names; you might change the SVN tag to include a "-rc1"
+ Try to accept the default suggestions for names; you might change the source control tag to include a "-rc1"
suffix indicating a release candidate number.</li>
<li><code>mvn release:perform</code></li>
</ol>
@@ -303,9 +304,8 @@
depend on the release version of previous steps. When you're done, you will have 1 or more
"closed" staging repositories, each having a unique URL.
</li-->
- <li>If necessary, run mvn release:prepare on the eclipse update site. This will create the svn tag,
- and create the needed artifacts in the target/eclipse-update-site. Or, you can create the tag
- yourself, and run mvn install -Papache-release.
+ <li>If necessary, run mvn release:prepare on the eclipse update site. This will create the source control tag,
+ and create the needed artifacts in the target/eclipse-update-site.
No need to run release:perform because no artifacts from this are going to Maven central distribution.
<p>Note that the target/eclipse-update-site will have .svn files - don't delete these - they're needed when
you decide to "publish" via comitting these to the release svn.</p></li>
Modified: uima/site/trunk/uima-website/docs/release.html
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/docs/release.html?rev=1873228&r1=1873227&r2=1873228&view=diff
==============================================================================
--- uima/site/trunk/uima-website/docs/release.html (original)
+++ uima/site/trunk/uima-website/docs/release.html Mon Jan 27 20:30:00 2020
@@ -309,6 +309,9 @@ A previous version of this page, with th
<ul><li>The UIMA SDK</li>
<li>UIMA-AS add-on</li>
<li>UIMA-CPP</li>
+ <li>uimaFIT</li>
+ <li>RUTA</li>
+ <li>DUCC</li>
<li>Individual Annotators, tooling, and other useful components (like the Simple Server)</li></ul>
In addition, it releases some Maven build tooling components that
need to be in the Maven repositories to support our Maven processes.
@@ -445,7 +448,7 @@ A previous version of this page, with th
<pre>mvn changes:jira-report -N </pre></p>
<p>Each time this plugin is run, it creates an updated report in the
- top level of this project. This report doesn't need to be checked into SVN.
+ top level of this project. This report doesn't need to be checked into source control.
It will be regenerated and copied into the distribution archives (source and binary)
during a release. The RELEASE_NOTES.html files have been updated to
refer to this generated report.</p>
@@ -511,7 +514,7 @@ A previous version of this page, with th
<p>
We use the maven-release-plugin to do the releasing. In the prepare phase, it updates the
trunk artifacts to remove the -SNAPSHOT suffix, commits it to trunk, and then does an
- SVN copy of the trunk to create the tag. Then it updates the trunk artifacts to the next
+ SVN copy or GIT Branch of the trunk or master to create the tag. Then it updates the trunk artifacts to the next
version-SNAPSHOT, and commits that.
</p>
<p>The release:perform checks out the tag and builds/tests/installs and deploys it to the
@@ -523,21 +526,21 @@ A previous version of this page, with th
<p class="note">In the past, we added a suffix representing the release candidate to the tag,
e.g. "-rc1" for release candidate 1, etc. However, the URL for this tag becomes part
of the released POM. After a successful vote, we would have upgraded the release candidate to
- the final release by renaming the tag in SVN. At that point, the URL in the
+ the final release by renaming the tag in source control. At that point, the URL in the
POM would have become invalid. For this reason, it was decided not to add the -rc1 to the
tag anymore.
</p>
<p>The release plugin automatically signs everything that needs signing using gpg. It also
builds the sources.jar, and one overall (for multi-module projects) source-release.zip file,
which can be later obtained and
- should be an (approximate) copy of the SVN tag for that artifact, and once unzipped, should be buildable,
+ should be an (approximate) copy of the tag for that artifact, and once unzipped, should be buildable,
using <code>mvn install</code>.
</p>
<p>Steps:
<ul>
- <li>Make sure all changes are checked into SVN. Then checkout (not export) from SVN the project(s)
+ <li>Make sure all changes are checked into source control. Then checkout (not export) from source control the project(s)
you'll be building, into a new "build" location, and do all the building from there.</li>
- <li>If you instead choose to build from your "working" SVN checkout, insure it's up-to-date with
+ <li>If you instead choose to build from your "working" source control checkout, insure it's up-to-date with
all changes that others may have checked into trunk.</li>
<li>Purge your local maven repository of artifacts being built by running in the
top level directory you'll be building from:
@@ -623,7 +626,7 @@ A previous version of this page, with th
</p>
<p style="margin-left:3em"><code>[mvn release:prepare]</code> If you've just done release:prepare,
you can reset things back to as they were before that command by issuing
- <code>mvn release:rollback</code>. Check to confirm that the svn tag for the
+ <code>mvn release:rollback</code>. Check to confirm that the source control tag for the
release candidate is deleted; if not, remove it manually.
</p>
<p style="margin-left:3em"><code>[mvn release:perform]</code> If you've done a release:perform, to
@@ -691,26 +694,21 @@ A previous version of this page, with th
Note that any JARs, Zips, Tars, tar.gz artifacts must be signed by the Release Manager.
</p>
<p>
- Although we have a spot in the distribution SVN under dev/uima for all the artifacts to be released
- via the Apache mirror system, you probably should not use this for
- release candidates, unless you suspect there won't be many of these (or they're small). This is because
- SVN retains forever all the files you put into it, so if we go through 8 release candidates, each having
- several multi-megabyte zip/tar files, these will just waste space in SVN.
- </p>
- <p>
- The alternative is to copy the release candidate for voting into your personal people.apache.org/~[user-id] space, and
- let testers/voters pull it from there.
+ We have a spot in the distribution SVN under dev/uima for all the artifacts to be released
+ via the Apache mirror system. This is where you put the
+ release candidates.
</p>
<p>Be sure to copy artifacts from the build-from tag spot, which should have a path like:
...[top level project]/target/checkout/target. Note this is not from [top level project]/target.
Doing this will guarantee that you're posting the artifacts built from the tag (which could be
different from the release:prepare build in /target if someone snuck in a svn commit at the right moment.)</p>
- <p>If you do use the distribution SVN for the release candidates,
- follow the
- <a href="saving-svn-resources.html">saving-svn-space</a> tricks if reasonable.
- Typically, for each release, we create a new directory for that, and place
- all files pertaining to that release underneath that directory.
- </p>
+ <p>Copy any artifacts (together with their signings) to the staging spot.
+ A suggested approach: Make a new dir in the build project, called svnUpload (or whatever), and
+ copy the artifacts (<b>from the build/target/checkout/target directory</b>)(typically the
+ bin/zip/tar and the source release and all the signature/checksums) into this dir. Then do the svn command:
+ <pre>cd the-svnUpload-directory
+svn import -m "commit msg, e.g. uimaj-2.8.0 rc5" . https://dist.apache.org/repos/dist/dev/uima/uimaj/n.n.n-rc1/artifacts
+</pre></p>
</blockquote>
</td></tr>
</table>
@@ -781,7 +779,7 @@ A previous version of this page, with th
<blockquote class="subsectionBody">
<p>The release candidate typically consists of
<ul><li>assembly source and binary distributions,</li>
- <li>the associated SVN tag, and</li>
+ <li>the associated source control tag, and</li>
<li>the individual Maven module artifacts.</li>
</ul>
</p>
@@ -795,7 +793,7 @@ A previous version of this page, with th
<p>
After things are staged, you write a note to the dev list, asking for an approval vote.
You need to provide the url(s) of the closed staging repository in the note so the approvers
- can find the code to check, the SVN tag corresponding to the release, and
+ can find the code to check, the source control tag corresponding to the release, and
if needed, and the place in the distribution SVN where the source and binary
distributions being proposed are found.
The [VOTE] email should be based on similar previous votes, and
Modified: uima/site/trunk/uima-website/xdocs/checklist-release.xml
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/xdocs/checklist-release.xml?rev=1873228&r1=1873227&r2=1873228&view=diff
==============================================================================
--- uima/site/trunk/uima-website/xdocs/checklist-release.xml (original)
+++ uima/site/trunk/uima-website/xdocs/checklist-release.xml Mon Jan 27 20:30:00 2020
@@ -36,11 +36,12 @@ under the License.
<li>Update the READMEs and RELEASE-NOTES.</li>
<li>Announce on the dev list that you're doing a release so others can get any changes in, and also
know not to be committing to trunk while you're in the middle of doing the release.</li>
- <li>Make a new build directory for this release, and svn checkout the trunk (svn "export" instead of checkout
+ <li>Make a new build directory for this release, and source control checkout the trunk or git clone the repo and switch to the branch (if needed).
+ (svn "export" instead of checkout
fails at a later commit step by the release plugin). This is so you can
preserve the build for later upload of selected artifacts to the distribution spot.
<p>
- If instead you are building from an existing checkout, do a svn update to be sure the workspace is up-to-date.
+ If instead you are building from an existing checkout, do a source control update to be sure the workspace is up-to-date.
</p>
</li>
<li>Purge your local maven repository of artifacts being built by running in the
@@ -53,7 +54,7 @@ under the License.
So, instead, just go to the .m2 .../uima/ node and consider deleting that directory.</p>
</li>
<li>Do a full build with deploy of the (last) snapshot before release: mvn clean deploy -Papache-release</li>
- <li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/</li>
+ <li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/ or the git branch for the tag.</li>
<li>If retrying a release candidate, <code><b>close</b></code> (and <code><b>drop</b></code> as appropriate) any previous repository.apache.org staging repo</li>
<!--li>(If remerging a branch: Note- best to do these if possible at the root of aggregations,
outside of Eclipse, so svn "batching" can work - will be quite a bit fraster)
@@ -82,7 +83,7 @@ under the License.
<code>mvn release:prepare -DdryRun -DautoVersionSubmodules</code>.
<li><code>mvn release:clean</code> to restore projects</li>
<li><code>mvn release:prepare [-DautoVersionSubmodules]</code>.
- Try to accept the default suggestions for names; you might change the SVN tag to include a "-rc1"
+ Try to accept the default suggestions for names; you might change the source control tag to include a "-rc1"
suffix indicating a release candidate number.</li>
<li><code>mvn release:perform</code></li>
</ol>
@@ -101,9 +102,8 @@ under the License.
depend on the release version of previous steps. When you're done, you will have 1 or more
"closed" staging repositories, each having a unique URL.
</li-->
- <li>If necessary, run mvn release:prepare on the eclipse update site. This will create the svn tag,
- and create the needed artifacts in the target/eclipse-update-site. Or, you can create the tag
- yourself, and run mvn install -Papache-release.
+ <li>If necessary, run mvn release:prepare on the eclipse update site. This will create the source control tag,
+ and create the needed artifacts in the target/eclipse-update-site.
No need to run release:perform because no artifacts from this are going to Maven central distribution.
<p>Note that the target/eclipse-update-site will have .svn files - don't delete these - they're needed when
you decide to "publish" via comitting these to the release svn.</p></li>
Modified: uima/site/trunk/uima-website/xdocs/release.xml
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/xdocs/release.xml?rev=1873228&r1=1873227&r2=1873228&view=diff
==============================================================================
--- uima/site/trunk/uima-website/xdocs/release.xml (original)
+++ uima/site/trunk/uima-website/xdocs/release.xml Mon Jan 27 20:30:00 2020
@@ -46,6 +46,9 @@ A previous version of this page, with th
<ul><li>The UIMA SDK</li>
<li>UIMA-AS add-on</li>
<li>UIMA-CPP</li>
+ <li>uimaFIT</li>
+ <li>RUTA</li>
+ <li>DUCC</li>
<li>Individual Annotators, tooling, and other useful components (like the Simple Server)</li></ul>
In addition, it releases some Maven build tooling components that
need to be in the Maven repositories to support our Maven processes.
@@ -149,7 +152,7 @@ A previous version of this page, with th
<pre>mvn changes:jira-report -N </pre></p>
<p>Each time this plugin is run, it creates an updated report in the
- top level of this project. This report doesn't need to be checked into SVN.
+ top level of this project. This report doesn't need to be checked into source control.
It will be regenerated and copied into the distribution archives (source and binary)
during a release. The RELEASE_NOTES.html files have been updated to
refer to this generated report.</p>
@@ -191,7 +194,7 @@ A previous version of this page, with th
<p>
We use the maven-release-plugin to do the releasing. In the prepare phase, it updates the
trunk artifacts to remove the -SNAPSHOT suffix, commits it to trunk, and then does an
- SVN copy of the trunk to create the tag. Then it updates the trunk artifacts to the next
+ SVN copy or GIT Branch of the trunk or master to create the tag. Then it updates the trunk artifacts to the next
version-SNAPSHOT, and commits that.
</p>
@@ -205,22 +208,22 @@ A previous version of this page, with th
<p class="note">In the past, we added a suffix representing the release candidate to the tag,
e.g. "-rc1" for release candidate 1, etc. However, the URL for this tag becomes part
of the released POM. After a successful vote, we would have upgraded the release candidate to
- the final release by renaming the tag in SVN. At that point, the URL in the
+ the final release by renaming the tag in source control. At that point, the URL in the
POM would have become invalid. For this reason, it was decided not to add the -rc1 to the
tag anymore.
</p>
<p>The release plugin automatically signs everything that needs signing using gpg. It also
builds the sources.jar, and one overall (for multi-module projects) source-release.zip file,
which can be later obtained and
- should be an (approximate) copy of the SVN tag for that artifact, and once unzipped, should be buildable,
+ should be an (approximate) copy of the tag for that artifact, and once unzipped, should be buildable,
using <code>mvn install</code>.
</p>
<p>Steps:
<ul>
- <li>Make sure all changes are checked into SVN. Then checkout (not export) from SVN the project(s)
+ <li>Make sure all changes are checked into source control. Then checkout (not export) from source control the project(s)
you'll be building, into a new "build" location, and do all the building from there.</li>
- <li>If you instead choose to build from your "working" SVN checkout, insure it's up-to-date with
+ <li>If you instead choose to build from your "working" source control checkout, insure it's up-to-date with
all changes that others may have checked into trunk.</li>
<li>Purge your local maven repository of artifacts being built by running in the
top level directory you'll be building from:
@@ -302,7 +305,7 @@ A previous version of this page, with th
</p>
<p style="margin-left:3em"><code>[mvn release:prepare]</code> If you've just done release:prepare,
you can reset things back to as they were before that command by issuing
- <code>mvn release:rollback</code>. Check to confirm that the svn tag for the
+ <code>mvn release:rollback</code>. Check to confirm that the source control tag for the
release candidate is deleted; if not, remove it manually.
</p>
<p style="margin-left:3em"><code>[mvn release:perform]</code> If you've done a release:perform, to
@@ -349,15 +352,9 @@ A previous version of this page, with th
Note that any JARs, Zips, Tars, tar.gz artifacts must be signed by the Release Manager.
</p>
<p>
- Although we have a spot in the distribution SVN under dev/uima for all the artifacts to be released
- via the Apache mirror system, you probably should not use this for
- release candidates, unless you suspect there won't be many of these (or they're small). This is because
- SVN retains forever all the files you put into it, so if we go through 8 release candidates, each having
- several multi-megabyte zip/tar files, these will just waste space in SVN.
- </p>
- <p>
- The alternative is to copy the release candidate for voting into your personal people.apache.org/~[user-id] space, and
- let testers/voters pull it from there.
+ We have a spot in the distribution SVN under dev/uima for all the artifacts to be released
+ via the Apache mirror system. This is where you put the
+ release candidates.
</p>
<p>Be sure to copy artifacts from the build-from tag spot, which should have a path like:
@@ -365,12 +362,13 @@ A previous version of this page, with th
Doing this will guarantee that you're posting the artifacts built from the tag (which could be
different from the release:prepare build in /target if someone snuck in a svn commit at the right moment.)</p>
- <p>If you do use the distribution SVN for the release candidates,
- follow the
- <a href="saving-svn-resources.html">saving-svn-space</a> tricks if reasonable.
- Typically, for each release, we create a new directory for that, and place
- all files pertaining to that release underneath that directory.
- </p>
+ <p>Copy any artifacts (together with their signings) to the staging spot.
+ A suggested approach: Make a new dir in the build project, called svnUpload (or whatever), and
+ copy the artifacts (<b>from the build/target/checkout/target directory</b>)(typically the
+ bin/zip/tar and the source release and all the signature/checksums) into this dir. Then do the svn command:
+ <pre>cd the-svnUpload-directory
+svn import -m "commit msg, e.g. uimaj-2.8.0 rc5" . https://dist.apache.org/repos/dist/dev/uima/uimaj/n.n.n-rc1/artifacts
+</pre></p>
</subsection>
<!--
@@ -461,7 +459,7 @@ A previous version of this page, with th
<subsection name='Doing The Release Vote'>
<p>The release candidate typically consists of
<ul><li>assembly source and binary distributions,</li>
- <li>the associated SVN tag, and</li>
+ <li>the associated source control tag, and</li>
<li>the individual Maven module artifacts.</li>
</ul>
</p>
@@ -475,7 +473,7 @@ A previous version of this page, with th
<p>
After things are staged, you write a note to the dev list, asking for an approval vote.
You need to provide the url(s) of the closed staging repository in the note so the approvers
- can find the code to check, the SVN tag corresponding to the release, and
+ can find the code to check, the source control tag corresponding to the release, and
if needed, and the place in the distribution SVN where the source and binary
distributions being proposed are found.
The [VOTE] email should be based on similar previous votes, and