Skip to content

Latest commit

 

History

History
109 lines (63 loc) · 3.39 KB

ReleaseManual.md

File metadata and controls

109 lines (63 loc) · 3.39 KB

Release Manual

This file include instructions followed by the core JEMMA team to make a new binary release.

Introduction

The main ismb/jemma repository includes an "umbrella" project which is only used to handle binaries of all modules. Source of all modules are each kept under separate projects, as listed in the components page. Normal developments are kept in the master of each module.

The release process is based on a clean envfolder, which can be checked out by using this script:

./scripts/jemma-generate-devenv.sh

Step-by-step instructions

In order to make a new binary release the following steps must be followed:

Verify that the current master of all project correctly builds on jenkins.

For a proper release all projects must be in "sun" status (= 5 subsequent successful daily builds)

Build all the stable binaries from all jemma projects.

This can be done inside the envfolder by typing:

./jemma/scripts/jemma-build-all.sh

Check which modules have been advanced since the last release

This can be done inside the envfolder by typing:

 ./jemma/scripts/dump-version-numbers.sh

Annotate on the side the new version of all bundles for whom gitversions.txt and pomversions.txt differ.

Upload new binaries on jemma-maven-repository

For all projects for whom the version number has been advanced, a new binary should be generated and deployed to the jemma maven repository.

This can be done inside the envfolder by useing the jemma-deploy script as in the following example:

./jemma/scripts/jemma-deploy.sh jemma.drafts.org.osgi.osgi.service.dal.functions 1.0.1

After all binaries have been deployed, the local jemma-maven-repository project should be committed and pushed to gh-pages.

Change and commit the main pom

For those bundles we should modify the main pom file inside the jemma project.

  • All versions in the pom.xml files in the ismb/jemma project should be advanced accordingly
  • The main release version in the pom.xml should be advanced (e.g. to 1.0.0)

The ismb/jemma configuration with the new version should be now committed and tested on jenkins.

Binary distribution

A binary distribution can be generated by typing:

./scripts/jemma-generate-release.sh

Test with development environment

Just to be sure new changes didn't break development environment, import and run the whole jemmma binary from a fresh distro.

A dev environment can be generated by typing:

./scripts/jemma-generate-devenv.sh

The whole set-up can be then imported into eclipse and lanunched.

Test with binary distribution

The same test should be done by unpacking and starting the binary distribution.

Tagging

After succesfull jenkin test, tag the current version of the master branch with the correct version number, making a jemma release.

You shall also tag all subprojects. Example:

./jemma/scripts/run-in-all-subfolders.sh git tag -a jemma-1.0.0-rc1 -m 'tagging for jemma release 1.0.0-rc1'

The associated binary distribution file can be uploaded as binary, attached to the release.

For major releases, we can also attach a tarball of the envfolder to have the full sources saved. Important note: remember to remove jemma-maven-repository and all .git files from the sources zip. E.g. :

find . -name .git -exec rm -rf {} +