Skip to content
This repository has been archived by the owner on Dec 21, 2021. It is now read-only.

Commit

Permalink
Update release building part of the dev doc - now refers to
Browse files Browse the repository at this point in the history 
git and not svn etc but process needs review by others as there
are now many more ways this can be done and git is still newish
  • Loading branch information
@mcpgovernance
mcpgovernance committed Jan 16, 2013
1 parent cb151a1 commit dbeafe7
Show file tree
Hide file tree
Showing 3 changed files with 98 additions and 98 deletions.
Binary file modified eng/developer/source/release/filerelease.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
1 change: 0 additions & 1 deletion eng/developer/source/release/index.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,4 +5,3 @@ Create GeoNetwork releases
:maxdepth: 2

stable.rst
branch.rst
195 changes: 98 additions & 97 deletions eng/developer/source/release/stable.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,168 +5,191 @@ Create a stable release for GeoNetwork

This guide details the process of performing a GeoNetwork release.

.. note :: * BRANCH: Branches are created for major stables releases and end with .x (for example 2.6.x)
* VERSION (for tag): version to release (for example 2.6.1)
* NEW_VERSION (for branch): next version (for example 2.6.2)
.. note:: * BRANCH: Branches are created for major stables releases and end with .x (for example 2.8.x)
* VERSION (for tag): version to release (for example 2.8.1)
* NEW_VERSION (for branch): next version (for example 2.8.2)

Release committee
-----------------

To create new releases a committee of 3-4 persons should be choosen. The members of the committee are
responsible of creating the releases following the steps described in this document to guarantee the
quality of releases.
To create new releases a committee of 3-4 persons should be chosen. The members of the committee are responsible for creating the releases following the steps described in this section.

A rotation policy can be use to select the person of the committee responsible of creating a release.
A rotation policy can be use to select a person from the committee who will be responsible for creating each release.

Notify developer lists
----------------------

It is good practice to notify the GeoNetwork developer list of the intention to make the release a few days in advance.

On the day the release is being made a warning mail **must** be send to the list asking that developers refrain from committing until the release tag has been created.
On the day the release is being made a warning mail **must** be sent to the list asking that developers refrain from committing until the release tag has been created.

Prerequisites
-------------

The following are necessary to perform a GeoNetwork release:
#. Commit access to `GeoNetwork git <https://github.com/geonetwork>`_
#. Administration rights to SourceForge server to publish the release

1. Commit access to `GeoNetwork svn <https://geonetwork.svn.sourceforge.net/svnroot/geonetwork/>`_
2. Administration rights to SourceForge server to publish the release

Update source code from SVN
Update source code from GIT
---------------------------

.. warning :: This steps must be performed in branch code.
.. warning:: These steps must be performed on a branch

1. Update or check out the **branch** to be released from.
2. Ensure that **svn status** yields no local modifications.
1. Check out the **branch** to be released

Test issues solved for new release
``````````````````````````````````
::
$ git clone --recursive https://github.com/geonetwork/core-geonetwork.git geonetwork-[VERSION]
$ cd geonetwork-[VERSION]
$ git checkout -b [VERSION] origin/[VERSION]
$ git remote-url set origin git@github.com:geonetwork/core-geonetwork.git

1. Create an installer ::
2. Set submodules to correct **branch**: Submodules are in subdirectories:``docs, gast, geoserver, installer, maven_repo, release``. The procedure for each submodule is the same:

::
$ cd <submodule>
$ git checkout -b [VERSION] origin/[VERSION]


Tests and issues must be resolved for the new release
`````````````````````````````````````````````````````

1. Build the application and run the integration tests in ``web-itests``

::
$ mvn clean install -Pitests
If tests are passed then proceed with the next step. Otherwise:

- If a critical bug is detected, fix before continuing.
- If a non-critical bug is detected, open a new ticket and set its version number to the next release and continue

2. Create an installer ::

$ mvn clean install
$ cd installer
$ ant
2. Install the installer located in ``geonetwork-[VERSION]`` folder

3. Test the issues included for the release, checking in `GeoNetwork trac <http://trac.osgeo.org/geonetwork/>`_.
3. Using the installer, install GeoNetwork in a folder called ``geonetwork-[VERSION]``

4. Test any issues relating to the release. Check `GeoNetwork trac <http://trac.osgeo.org/geonetwork/>`_.

If tests are passed, proceed with the release. Otherwise:
If all tests pass, proceed with the release. Otherwise:

1. If any critical bug detected, fix before continue with the release.
2. If no critical bug detected, move the bug to next release and continue with release
- If a critical bug is detected, fix before continuing with the release.
- If a non-critical bug is detected, set the version number of the ticket to the next release and continue

.. note :: **to discuss and get feedback**
This approach implicates a code freeze in branch until the release is done, if all test are ok (no bugs found in tests or non critical bugs), 1 day or less is ok.
This approach requires a code freeze on the branch until the release is done, if all test are ok (no bugs found in tests or non critical bugs), 1 day or less is ok.

If a critical bug is detected, the code freeze can take some time if a bug is complicated to fix. To avoid this code freeze some alternatives can be considered:
If a critical bug is detected, the code freeze can take some time if a bug is complicated to fix. To avoid a prolonged code freeze some alternatives can be considered:

1. If there is a commit on the branch before the critical fix is commited, it will be part of the release (properly tested in a new release cycle)
2. Create a tag anyway and commit the critical fix to that tag/branch/trunk so there is no freeze on the branch at all.
No other commits should happen on a tag, except critical bug fixes. This allows people to commit on the branch while the critical bug is been solved.
#. If there is a commit on the branch before the critical fix is committed then it will be part of the release (properly tested in a new release cycle)
#. Fork the repository and commit the critical fix to that fork, then pull the fix into the branch. This allows other developers to commit on the branch while the critical bug is being solved.

Update changes.txt file
-----------------------

1. Add an entry to ``docs/changes.txt`` describing the changes in this new release, using the following template.

Comments from the SVN commits are used to extract the most important changes (e.g. use ``svn log -r 7219:HEAD > ~/changes264.txt`` to obtain these. Some cleanup is required before adding them in the changes.txt document)
Comments from the GIT commits are used to extract the most important changes (use ``git help log`` to work out what you need eg. git log --since="2 weeks ago"). Some cleanup may be required before the log output can be added to the changes.txt document)

::
================================================================================
===
=== GeoNetwork [VERSION]: List of changes
===
================================================================================
--------------------------------------------------------------------------------
--- Bug fixes
--------------------------------------------------------------------------------
- Fix fo issue #NUMBER: Description of fix
- Fix fo issue #NUMBER: Description of fix
- ...

--------------------------------------------------------------------------------
--- Changes
--------------------------------------------------------------------------------
- Description of change
- Description of change
- ...
================================================================================
===
=== GeoNetwork [VERSION]: List of changes
===
================================================================================
--------------------------------------------------------------------------------
--- Bug fixes
--------------------------------------------------------------------------------
- Fix fo issue #NUMBER: Description of fix
- Fix fo issue #NUMBER: Description of fix
- ...
--------------------------------------------------------------------------------
--- Changes
--------------------------------------------------------------------------------
- Description of change
- Description of change
- ...
2. Commit ``docs/changes.txt`` file ::

$ svn commit -m "Updating CHANGES for [VERSION]" docs/changes.txt
$ git commit -m "Updating CHANGES for [VERSION]" docs/changes.txt
$ git push


Update version numbers for a release
------------------------------------

A \*NIX (Linux, OSX etc..) operating system can use the following batch script.
A \*NIX (Linux, OSX etc..) operating system can use the following shell script.

1. Execute in root of the **branch** source tree ``updateReleaseVersions.sh``. Example to create version 2.6.1 from 2.6.1-SNAPSHOT ::

$ ./updateReleaseVersions.sh 2.6.1

2. Commit updated files ::

$ svn commit -m "Updated files version to [VERSION]" .
$ git commit -a -m "Updated files version to [VERSION]"
$ git push

Create release tag
------------------

1. Create a tag for the release ::

$ svn copy -m "Create tag for release [VERSION]"
https://geonetwork.svn.sourceforge.net/svnroot/geonetwork/branches/[BRANCH]
https://geonetwork.svn.sourceforge.net/svnroot/geonetwork/tags/[VERSION]
$ git tag -a [VERSION] -m "Create tag for release [VERSION]"

2. Checkout the release tag ::
2. Push the tag to github::

$ svn co https://geonetwork.svn.sourceforge.net/svnroot/geonetwork/tags/[VERSION]
$ git push origin [VERSION]


Build release artifacts
-----------------------

.. warning :: All operations for the remainder of this guide must be performed from the release tag, not the branch. Unless otherwise stated.
.. warning :: All operations for the remainder of this guide must be performed from the release tag unless otherwise stated.
1. Uncomment doc sections in ``web/pom.xml``::
1. Uncomment doc sections in ``web/pom.xml``

::

<webResources>
<resource>
<webResources>
<resource>
<directory>../docs/eng/users/build/html</directory>
<targetPath>docs/eng/users</targetPath>
</resource>
...
</webResources>
</webResources>


2. Build documentation. In ``docs`` folder, execute ::

$ mvn clean install

.. note :: Building the GeoNetwork documentation requires the following be installed:
.. note:: Building the GeoNetwork documentation requires the following be installed:

* `Sphinx <http://sphinx.pocoo.org/>`_, version 0.6 or greater
* `pdflatex <http://www.tug.org/applications/pdftex/>`_ utility to build PDF files
* Make utility
* `Sphinx <http://sphinx.pocoo.org/>`_, version 0.6 or greater (sphinx-doc on ubuntu/debian)
* `TeX Live <http://www.tug.org/texlive>`_ (texlive-full on ubuntu/debian)
* make utility

3. Compile from the root of the source tree ::
3. Compile and build from the root of the source tree ::

$ mvn clean install
WAR distribution
----------------

After building the release articfacts in previous steps, the war distribution of the new release is located in: ``web/target/geonetwork.war``
After building the release artifacts in the previous steps, the war distribution of the new release will be: ``web/target/geonetwork.war``


Build installers
----------------

To build the Windows and platform independent installers, execute the next command in ``installer`` folder ::
To build the Windows and platform independent installers, execute the next command in the ``installer`` folder ::

$ ant
Expand All @@ -181,7 +204,7 @@ All of the artifacts generated so far need to be uploaded to the SourceForce Fil
1. WAR distribution
2. Installers (exe and jar)

.. note :: This step requires administrative privileges in SourceForge for the GeoNetwork opensource project.
.. note:: This step requires administrative privileges in SourceForge for the GeoNetwork opensource project.

1. Log in to `SourceForge <http://sourceforge.net/account/login.php>`_.

Expand Down Expand Up @@ -210,7 +233,7 @@ The (i) button allows to set the default operating systems for each installer (.
Update geonetwork-opensource website
------------------------------------

The website requires updates to reflect the new release. Update the version number and add a new news entry in the following files:
The website requires updates to reflect the new release. Update the version number and add a new news entry in the following files::

website/docsrc/conf.py
website/docsrc/docs.rst
Expand All @@ -235,41 +258,19 @@ SourceForge

``TODO``: Do we create SourceForge notifications?

Close the tag
-------------

.. warning :: This script must be configured in SVN server.
After a version is released we must "close" the tag to prevent commits using a *pre-commit* script in SVN like ::

#!/bin/sh

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook

# Committing to tags is not allowed
$SVNLOOK changed -t "$TXN" "$REPOS" | grep "^U\W*tags" && /bin/echo "Cannot commit to tags!" 1>&2 && exit 1

# All checks passed, so allow the commit.
exit 0


``TODO``: Check the regular expression to identify the tags. After creating a tag we commit the new versions in tag, so we need to close the tag when the release it's finished.

Upgrade branch pom versions
---------------------------

.. warning :: This steps must be performed using branch code.
After a release has being created the branch version number must be increased to next release version. On a \*NIX (Linux, OSX etc..) operating system you can use the following batch script.
After a release has been created, the branch version number must be set to the version number of the next release. On a \*NIX (Linux, OSX etc..) operating system you can use the shell script ``updateBranchVersions.sh`` to do this.

1. From the root of the **branch** source tree execute the script ``updateBranchVersions.sh``. To update from version 2.6.1-SNAPSHOT to 2.6.2-SNAPSHOT for example ::

$ ./updateBranchVersions.sh 2.6.1 2.6.2

2. Commit the updated files ::

$ svn commit -m "Updated files version to [VERSION]-SNAPSHOT" .
$ git commit -a -m "Updated files version to [VERSION]-SNAPSHOT"
$ git push

0 comments on commit dbeafe7

Please sign in to comment.