sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From desruisse...@apache.org
Subject svn commit: r1506742 - in /sis/site/trunk/content: release-management-setup.mdtext release-management.mdtext
Date Wed, 24 Jul 2013 21:59:55 GMT
Author: desruisseaux
Date: Wed Jul 24 21:59:54 2013
New Revision: 1506742

URL: http://svn.apache.org/r1506742
Log:
In deployment instruction, replaced usage of non-dry 'mvn release:prepare' by manual creation
of the tag.
We keep the dry run of 'mvn release:prepare' for verification purpose. In our tries, the non-dry
run fails
when it try to create the tag. For a yet unknown reason, the release plugin tries to create
a tag for revision 0.

Modified:
    sis/site/trunk/content/release-management-setup.mdtext
    sis/site/trunk/content/release-management.mdtext

Modified: sis/site/trunk/content/release-management-setup.mdtext
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/release-management-setup.mdtext?rev=1506742&r1=1506741&r2=1506742&view=diff
==============================================================================
--- sis/site/trunk/content/release-management-setup.mdtext [UTF-8] (original)
+++ sis/site/trunk/content/release-management-setup.mdtext [UTF-8] Wed Jul 24 21:59:54 2013
@@ -192,7 +192,7 @@ together with the PGP key name:
 Notes:
 
   * Do not store the PGP passphrase in the `settings.xml` file.
-    We will use the `gpg-agent` instead, as described in the [release management][release-management.html]
page.
+    We will use the `gpg-agent` instead, as described in the [release management](release-management.html)
page.
   * The `<user.name>` property in the `<profile>` section can be omitted
     if the Apache user name matches the user name on the local operating system.
   * The `<gpg.keyname>` property in the `<profile>` section can be omitted if
GPG contains only one private key.

Modified: sis/site/trunk/content/release-management.mdtext
URL: http://svn.apache.org/viewvc/sis/site/trunk/content/release-management.mdtext?rev=1506742&r1=1506741&r2=1506742&view=diff
==============================================================================
--- sis/site/trunk/content/release-management.mdtext [UTF-8] (original)
+++ sis/site/trunk/content/release-management.mdtext [UTF-8] Wed Jul 24 21:59:54 2013
@@ -109,8 +109,8 @@ It will not yet be published on `http://
 
 
 
-Create a branch
-===============
+Create branch
+=============
 
 Execute the following command:
 
@@ -131,7 +131,7 @@ We need to update the Subversion URL and
 but also in a few Java files. The following command performs the replacement using Ant:
 
     :::bash
-    ant -buildfile core/sis-build-helper/src/main/ant/prepare-branch.xml -Dsis.version=$NEW_VERSION
+    ant -buildfile core/sis-build-helper/src/main/ant/prepare-release.xml branch -Dsis.version=$NEW_VERSION
 
 Open the root `pom.xml` file in an editor and remove the following sections:
 
@@ -154,11 +154,6 @@ Commit the changes on the branch:
 Verify content
 --------------
 
-Makes sure that the above modifications does not break compilation.
-
-    :::bash
-    mvn install --define skipTests=true
-
 Starts the GPG agent if not already done.
 This is for avoiding to be prompted many time for the passphrase in every modules to be built
by Maven.
 Note that MacOS users can skip this step if their passphrase is stored in the OS keychain,
@@ -167,7 +162,7 @@ Note that MacOS users can skip this step
     eval $(gpg-agent --daemon)
 
 Try a dry run of the `release:prepare` goal. This goals checks for `SNAPSHOT` dependencies
in `pom.xml` files.
-It will not complete the prepare goal until all `SNAPSHOT` dependencies are resolved.
+It will not complete the prepare goal until all snapshot dependencies are resolved.
 If anything goes wrong, the directory can be cleaned by running the `release:clean` goal
 before to fix the problem and try again.
 
@@ -176,62 +171,80 @@ before to fix the problem and try again.
         --define autoVersionSubmodules=true --define updateWorkingCopyVersions=false --define
dryRun=true
 
 The dry run will not commit any changes back to SVN. Instead, it will create `pom.xml.tag`
files containing
-the changes that would have been committed to SVN. This gives us the opportunity to verify
that the release
-process will complete as expected.
+the changes that would have been committed to SVN. We keep those files for verification purpose
in the next section.
 
-Compare the original `pom.xml` files with the `pom.xml.tag` ones to see if the license or
any other info has been removed.
-This has been known to happen if the starting `<project>` tag is not on a single line.
-The only things that should be different between these files are the `<version>` and
`<scm>` elements.
-Comparisons can be performed for all files with the following command:
+Verify signature for all files:
 
     :::bash
-    find . -name "pom.xml" -print -exec diff '{}' '{}'.tag \;
+    find . -name "sis-*.asc" -exec gpg --verify '{}' \;
 
-View the `release.properties` file and check for the following properties:
 
-  * `exec.additionalArguments` shall contains `-Papache-release`
-    (this profile shall be implied even if not explicitely specified on the command line).
-  * `project.scm.org.apache.sis:parent.connection` shall be (ignoring escape characters)
-    `scm:svn:http://svn.apache.org/repos/asf/sis/branches/$NEW_VERSION`.
 
-Verify signature for all files:
+Create tag
+==========
+
+In theory, the next commands would be a real (non-dry) run of `mvn release:prepare`, followed
by `mvn release:perform`.
+However we perform those steps manually rather than relying on Maven for the following reasons:
+
+  * Perform some additional changes on the tag.
+  * Reduce the amount of commits on SVN (avoid a rollback in branch directory).
+  * Give more opportunities to take action before commit in case of problems.
+  * We need a separated `install` phase first, then a `site` phase at deploy time
+    (even if the site is not deployed) for proper execution of SIS custom taglets.
+
+First, create the branch:
 
     :::bash
-    find . -name "sis-*.asc" -exec gpg --verify '{}' \;
+    svn copy https://svn.apache.org/repos/asf/sis/branches/$NEW_VERSION \
+             https://svn.apache.org/repos/asf/sis/tags/$NEW_VERSION \
+             --message "Create the $NEW_VERSION tag."
 
-Clean and ensure that there is no modified files, i.e. that the last `svn` command produces
no output:
+Checkout:
 
     :::bash
-    mvn release:clean
-    svn status
+    cd ../../tags
+    svn checkout https://svn.apache.org/repos/asf/sis/tags/$NEW_VERSION
+    cd $NEW_VERSION
 
+Update versions number in `pom.xml` files (like what `mvn release:prepare` would have done),
+plus some additional files:
 
+    :::bash
+    ant -buildfile core/sis-build-helper/src/main/ant/prepare-release.xml tag -Dsis.version=$NEW_VERSION
 
-Deploy the release
-==================
+Compare with the modifications done by `mvn release:prepare`. The following command should
report no difference,
+ignoring the license or other information that may have been removed by the Maven plugin
+(this has been known to happen if the starting `<project>` tag is not on a single line).
+
+    :::bash
+    find . -name "pom.xml" -exec diff '{}' ../../branches/$NEW_VERSION/'{}'.tag \;
+
+Commit:
+
+    :::bash
+    svn commit --message "Fix version number and SVN directory."
 
-Run the `release:prepare` goal for real this time. The command is identical to the one in
the
-_Create a branch_ section except for the `dryRun` property, which is omitted.
-This command will create the tag and commit the changes on SVN.
+Clean the branch, since we will not need it anymore:
 
     :::bash
-    mvn release:prepare --define releaseVersion=$NEW_VERSION --define tag=$NEW_VERSION \
-        --define autoVersionSubmodules=true --define updateWorkingCopyVersions=false
+    cd ../../branches/$NEW_VERSION
+    mvn release:clean
+    mvn clean
+    cd ../../tags/$NEW_VERSION
+
 
-In theory, the next command would be `mvn release:perform`.
-However in fact, that command only checks out the project from tag folder and then run the
`deploy` phase.
-We need to perform those commands manually, because we need a separated `install` phase first,
-then a `site` phase at deploy time (even if the site is not deployed) for proper execution
of SIS custom taglets.
 
-First, move to a directory containing the project tags (presumed to be `../../tags` in the
following
-command, but can be replaced by anything else), then checkout and deploy:
+Deploy the release
+==================
+
+Ensure that the current directory is `tags/$NEW_VERSION`.
+Execute an `install` phase first (this is mandatory because of our custom `sis-build-helper'
plugin), then deploy.
+Note that the `site` phase is required, even if we will not deploy the site,
+for proper execution of our custom Javadoc taglets.
 
     :::bash
-    cd ../../tags
-    svn checkout https://svn.apache.org/repos/asf/sis/tags/$NEW_VERSION
-    cd $NEW_VERSION
-    mvn clean install --define skipTests=true
-    mvn site deploy --activate-profiles apache-release
+    mvn clean install
+    mvn site deploy --activate-profiles apache-release --define skipTests=true
 
 
 



Mime
View raw message