Child pages
  • Configuration Management
Skip to end of metadata
Go to start of metadata

BEAM VCS Configuration

Subversion repository

The location of the BEAM Subversion repository is https://www.brockmann-consult.de/svn/os. The repository can be read by anyone, but is writeable for BEAM team members only.

The tree structure of the BEAM 4 subversion repository is

   +- beam-4.x/
       +- trunk/
       |  +- beam-core/
       |  +- beam-ui/
       |  +- ...
       +- tags/
       |  +- 4.1
       |     +- beam-core/
       |     +- beam-ui/
       |     +- ...
       +- branches/
          +- 4.1.x
             +- beam-core/
             +- beam-ui/
             +- ...

The trunk directory contains the sources for the current development trunk, e.g. 4.2-SNAPSHOT. The tags directory contains released BEAM versions, e.g. 4.1. Tags are considered to be read only, they should never be changed by team members once the software has been released. The branches directory contains the maintenance branches for the releases contained in tags, e.g. 4.1.x. Most commonly, changes in a branch are merged into trunk.

The same tree is used for the Ceres sources located in the same repository, which are required by BEAM for the module runtime functionality, e.g. dynamic updates and installations. The Ceres version required by BEAM 4.1 is 0.6, the one for 4.2-SNAPSHOT is 0.7-SNAPSHOT.

A BEAM branch will only be used to create module updates, which are updated by clients using the VISAT module manager (sources located in ceres). In theory, it should not be necessary to create new BEAM installers from a branch.

      ^     
      |
      | 4.3-SNAPSHOT
      |                 4.2      4.2.x
      o----------------->o-------->o--------> Module updates for BEAM 4.2
      ^                
      | 4.2-SNAPSHOT 
      |                 4.1      4.1.x
      o----------------->o-------->o--------> Module updates for BEAM 4.1
      ^                       
      | 4.1-SNAPSHOT
      |         
    trunk               tags    branches

Mapping to local project directories

Directory in the Subversion repository are mapped to local project directories as follows:

Subversion

Local

Descripion

ceres/trunk

$MY_PROJECTS/ceres-0.x

Current 0.7-SNAPSHOT

ceres/branches/0.6.x

$MY_PROJECTS/ceres-0.6.x

Maintenance for 0.6

ceres/tags/0.6

$MY_PROJECTS/ceres-0.6

0.6 Release

beam-4.x/trunk

$MY_PROJECTS/beam-4.x

Current 4.2-SNAPSHOT

beam-4.x/branches/4.1.x

$MY_PROJECTS/ceres-4.1.x

Maintenance for 4.1

beam-4.x/tags/4.1

$MY_PROJECTS/beam-4.1

4.1 Release

Rule: If an x appears in the version part of the directory name, it is an actively developed project. If no x appears, don't change the source, because it's a released version and the code is fixed.

See also Build from Source.

BEAM Module Configuration

Module names

Modules belonging to the standard installation of BEAM are named after the pattern beam-<name>. The name of the resulting Java archive is then beam-<name>-<version>.jar.

Module versions

The version naming used for BEAM modules is similar to the one used by the Maven build tool. The general version syntax is

   <major>.<minor>[.<micro>][.<qualifier>]

or

   <major>.<minor>[.<micro>][-<qualifier>]

The qualifier SNAPSHOT marks module versions as being in development.

BEAM module versions occur in two different places: In the version element of the

  1. Maven project file $MODULE_HOME/pom.xml
  2. BEAM module manifest file $MODULE_HOME/src/main/resources/module.xml

New Modules get the version number 1.0-SNAPSHOT. Only major feature changes or binary incompatibility due to a BEAM API change or changes of the module's extension-point API will cause an increase of the major part of the version number.

Changing version numbers of existing modules

If you change code in an existing module, be sure to update the version number according

  1. to the current state of the module and
  2. to the development stream (trunk or branch) of BEAM.

Version numbering in the development stream (trunk):

Change type

Previous version

New version

Bug fix

X.Y[.Z]-SNAPSHOT

X.Y[.Z]-SNAPSHOT

Bug fix

X.Y

X.Y.1-SNAPSHOT

Bug fix

X.Y.Z

X.Y.(Z+1)-SNAPSHOT

Minor change 1

X.Y[.Z]-SNAPSHOT

X.Y[.Z]-SNAPSHOT

Minor change 1

X.Y[.Z]

X.(Y+1)-SNAPSHOT

Release

X.Y[.Z]-SNAPSHOT

X.Y[.Z]

Patch from branch Z'

X.Y[.Z]

X.Y.(100*Z'+Z)

Version numbering in the maintenance stream (branch):

Change type

Previous version

New version

Bug fix

X.Y[.Z]-SNAPSHOT

X.Y[.Z]-SNAPSHOT

Bug fix

X.Y

X.Y.1-SNAPSHOT

Bug fix

X.Y.Z

X.Y.(Z+1)-SNAPSHOT

Minor change 1

X.Y[.Z]-SNAPSHOT

X.Y[.Z]-SNAPSHOT

Minor change 1

X.Y[.Z]

X.(Y+1)-SNAPSHOT

Release

X.Y[.Z]-SNAPSHOT

X.Y[.Z]

(1) Minor feature added or binary incompatibility due to a BEAM API change or change of the module's extension-point API.

After changing a version number make sure

  • to update all dependencies in dependent modules manifests and Maven POMs. Also
  • to document all changes in the changelog element in the module manifest file. e.g.:
    <module>
        ...
        <version>4.0.1-SNAPSHOT</version>
        ...
        <changelog>
            <![CDATA[
            <p>Changes in 4.0.1
            <ul>
                <li>[BEAM-622] Use mouse wheel for zooming</li>
                <li>[BEAM-614] Not possible to re-select item in ...</li>
            </ul></p>
            ]]>
        </changelog>
        ...
    </module>
    

When to change the version number of a module?

Major and minor BEAM releases

We change the version number of all BEAM system modules when we have a major and minor release. The system modules are

  • ceres-*
  • beam-core
  • beam-ui
  • beam-gpf
  • beam-processing
  • beam-visat-rcp
  • beam-visat

Micro BEAM releases and module updates (maintenance)

We increase the micro version number on code changes which affects the API or changes the module's behaviour. The version number of dependent modules do not automatically increase as well.