sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1050258 - in /websites/staging/sis/trunk/content: ./ release-management.html
Date Wed, 18 Sep 2019 17:47:31 GMT
Author: buildbot
Date: Wed Sep 18 17:47:31 2019
New Revision: 1050258

Staging update by buildbot for sis

    websites/staging/sis/trunk/content/   (props changed)

Propchange: websites/staging/sis/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Wed Sep 18 17:47:31 2019
@@ -1 +1 @@

Modified: websites/staging/sis/trunk/content/release-management.html
--- websites/staging/sis/trunk/content/release-management.html (original)
+++ websites/staging/sis/trunk/content/release-management.html Wed Sep 18 17:47:31 2019
@@ -109,6 +109,7 @@ The intended audiences are SIS release m
 <li><a href="#prepare-source">Review project status before branching</a><ul>
+<li><a href="#update-crs-list">Update the list of supported CRS</a></li>
 <li><a href="#release-notes">Prepare release notes</a></li>
@@ -157,16 +158,15 @@ The intended audiences are SIS release m
 <p>For all instructions in this page, <code>$OLD_VERSION</code> and <code>$NEW_VERSION</code>
stand for the version
 number of the previous and the new release respectively, and <code>$RELEASE_CANDIDATE</code>
stands for
 the current release attempt. Those versions shall be set on the command line like below (Unix):</p>
-<div class="codehilite"><pre><span class="nb">export </span><span
class="nv">OLD_VERSION</span><span class="o">=</span>0.8
+<div class="codehilite"><pre>gpg --list-keys                     <span class="c">#
For getting the value to put in &lt;your key ID&gt;</span>
+<span class="nb">unset </span>PATH_TO_FX
+<span class="nb">export </span><span class="nv">OLD_VERSION</span><span
 <span class="nb">export </span><span class="nv">NEW_VERSION</span><span
 <span class="nb">export </span><span class="nv">RELEASE_CANDIDATE</span><span
-<span class="nb">export </span><span class="nv">SIGNING_KEY</span><span
class="o">=</span>&lt;your key ID&gt;
-<span class="nb">unset </span>PATH_TO_FX
+<span class="nb">export </span><span class="nv">SIGNING_KEY</span><span
class="o">=</span>&lt;your key ID&gt;    <span class="c"># hexadecimal
number with 8 or 40 digits.</span>
-<p>The key ID value is an hexadecimal numbers with 8 digits (may be the last 8 digits
of a 40 digits number).
-It can be found be executing <code>gpg --list-keys</code>.</p>
 <h2 id="directory-layout">Directory layout<a class="headerlink" href="#directory-layout"
title="Permanent link">&para;</a></h2>
 <p>The steps described in this page assume the following directory layout (some directories
will be created as
 a result of the steps). Any other layout can be used. However if the layout differs, then
the relative paths
@@ -190,6 +190,7 @@ Those changes need to be applied on the
 <li><code>DOWNLOAD_URL</code> in <code>application/sis-console/src/main/java/org/apache/sis/console/</code>
 <li><code>&lt;sis.non-free.version&gt;</code> in root <code>pom.xml</code>
+<li>Also review the <code>README</code> and <code>NOTICE</code>
files in root directory.</li>
 <p>Commit and merge with other branches up to master.</p>
 <div class="codehilite"><pre>git commit --message<span class="o">=</span><span
class="s2">&quot;Set the EPSG geodetic dataset URL to its expected location after release.&quot;</span>
@@ -200,9 +201,11 @@ Those changes need to be applied on the
 <p>Before to start the release process, we need to test more extensively the master.
 The tests described below often reveal errors that were unnoticed in daily builds.
 It is better to detect and fix them before to create the release branch.
-First review and update the <code>README</code> and <code>NOTICE</code>
files on the source code repository.
+First, ensure that a PostgreSQL server is running and listening to the default port on local
+(optional but recommended for more exhaustive testing).
 Then execute the following commands and fix as much warnings as practical:</p>
-<div class="codehilite"><pre>mvn clean install --define org.apache.sis.test.extensive<span
class="o">=</span><span class="nb">true</span>
+<div class="codehilite"><pre>systemctl start postgresql.service        <span
class="c"># Optional — exact command depends on Linux distribution.</span>
+mvn clean install --define org.apache.sis.test.extensive<span class="o">=</span><span
 mvn javadoc:aggregate
@@ -217,6 +220,21 @@ mvn <span class="nb">test</span>
+<h2 id="update-crs-list">Update the list of supported CRS<a class="headerlink" href="#update-crs-list"
title="Permanent link">&para;</a></h2>
+<p>The following steps should have been done after SIS upgraded EPSG data,
+but it is useful to execute them again in case they have been forgotten,
+and also because failure to execute them may reveal problems.</p>
+<p>First, open the <code>CoordinateOperationMethods</code> Java class and
executes its <code>main</code> method, for example from an IDE.
+If successful, a <code>CoordinateOperationMethods.html</code> file will have
been generated in the current directory.
+Open that file in a browser and verify that information are okay, in particular the version
number in the first paragraph.
+If okay, move that file to the site checkout in the <code>content/tables/</code>
+<p>Next, open the <code>CoordinateReferenceSystems</code> class. Before
to execute, we need to perform a temporary hack:
+open the <code>AuthorityCodes</code> class, search <code>DEPRECATED=0</code>
(it appears in a SQL fragment) and replace by <code>(DEPRECATED=0 OR TRUE)</code>.
+Do not commit! The intent of this hack is to include deprecated codes in the CRS list to
be generated.
+Those codes will appear with strike for making clear that they are deprecated.
+Next execute the <code>CoordinateReferenceSystems</code> main method,
+move the generated <code>CoordinateReferenceSystems.html</code> page to the <code>content/tables/</code>
directory of the site,
+and finally revert the hack in <code>AuthorityCodes</code> class.</p>
 <h2 id="release-notes">Prepare release notes<a class="headerlink" href="#release-notes"
title="Permanent link">&para;</a></h2>
 <p>We update JIRA soon because doing so is sometime a reminder of uncompleted tasks
in source code.
 Update <a href="">JIRA</a> tasks and
prepare release notes as below:</p>
@@ -423,11 +441,7 @@ mvn clean
 <h1 id="stage">Stage the source, binary and javadoc artifacts<a class="headerlink"
href="#stage" title="Permanent link">&para;</a></h1>
-<p>Generate the Javadoc. While not mandatory, we suggest to use JDK 8 or above for
getting the new look and feel,
-getting the Javadoc enhancements expected in future JDK releases (more dynamic pages),
-avoiding the security vulnerability discovered in the Javadoc tools of older JDK releases,
-and keeping the <code>diff</code> smaller on the SVN repository of SIS web site.
-If JDK8 is <em>not</em> used, then omit the <code>cp</code> command
+<p>Generate the Javadoc:</p>
 <div class="codehilite"><pre><span class="nb">cd</span> <span
 mvn javadoc:aggregate
 <span class="nb">cd </span>target/site
@@ -436,16 +450,6 @@ zip -9 -r apache-sis-<span class="nv">$N
-<p>Note: if Javadoc fails because of <a href="">JDK-8061305</a>
-a workaround is to temporarily copy the OpenGIS annotations into the <code>sis-metadata</code>
-(only the time needed for building the javadoc):</p>
-<div class="codehilite"><pre>mkdir core/sis-metadata/src/main/java/org/opengis
-<span class="nb">cd </span>core/sis-metadata/src/main/java/org/opengis
-ln -s &lt;path to GeoAPI project&gt;/geoapi/src/main/java/org/opengis/annotation
-<span class="nb">cd</span> -
 <h2 id="dist">Initialize the distribution directory<a class="headerlink" href="#dist"
title="Permanent link">&para;</a></h2>
 <p>Create the directory for the new version and release candidate within the distribution
 The <code>$RELEASE_CANDIDATE</code> variable shall be the number of current release

View raw message