Page tree
Skip to end of metadata
Go to start of metadata

Guidelines for Release branches:

  1. Creates new release branch release/{releaseTagName} based on the develop branch and switches to that branch. {releaseName} should contain the tag, by which the master branch is tagged when the release branch is finished 
    1. git flow release start {releaseTagName} 

      1. releaseTagName should be in the form release-X.Y.Z

        1. for UV-Plugin-DevEnv the format for the tag is: UV_Plugin-DevEnv_v2.1.5

        2. for UV-Core the format for the tag is: UV_Core_v2.2.0

        3. for UV-Plugins the format for the tag is: UV_Plugins_v2.2.1
      2. optionally, you may supplement with commit sha-1 hash to define from which commit the release branch is created

  2. Work on that branch as needed
  3. Adjust the version number of the release & commit on that branch
    1. see How to adjust the versions
  4. Publish the release branch
    1. git flow release publish {releaseName}
  5. Test that the branch can be compiled by running Jenkins jobs:
    1. https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20Plugin-DevEnv%20-%20pre-release/
    2. https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20Core%20-%20pre-release/
    3. https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20Plugins%20-%20pre-release/
      1. Note: adjust release branch for all of them
      2. Alternatively Travis CI may be used
  6. Check that UV-Plugins - debian - has all the DPUs included, with proper versions: 
    1. https://github.com/UnifiedViews/Plugins/blob/master/pom.xml
    2. https://github.com/UnifiedViews/Plugins/blob/release/UV_Plugins_v2.2.2/debian/deploy-dpus.sh
  7. Test creation of the Debian packages
    1. Adjust Jenkins tasks (see below) with the proper release branches and D-debian-package-version
      1. Core: https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Prepare%20packages%20for%20Core%20-%20pre-release/
      2. Plugins: https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Prepare%20packages%20for%20Plugins%20-%20pre-release/
    2. Run https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Prepare%20packages%20for%20Core%20-%20pre-release/
      1. it automatically runs also:
        1. https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Prepare%20packages%20for%20Plugins%20-%20pre-release/
        2. Publishing the debian packages to packages.unifiedviews.eu: https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Publish%20pre-release/
    3. Debian packages are available at packages.unifiedviews.eu/debian-pre-release
    4. Test the packages 
      1. On Fresh Debian installation
        1. VirtualBox: https://docs.google.com/document/d/1SuCJsiu35ZTuhFBHO2c2B5t9xuGo5kDeaRmX2I5PoYI/edit
      2. To install the Debian packages from pre-release location: 
        1. rm /etc/apt/sources.list.d/*

        2. echo "deb http://packages.unifiedviews.eu/debian-pre-release/ wheezy main" /etc/apt/sources.list.d/unifiedviews.list

        3. wget -O - http://packages.unifiedviews.eu/key/unifiedviews.gpg.key | apt-key add -

        4. aptitude update

        5. Then you may follow: Installation Guide

  8. Create release for plugins-devEnv
    1. Merges feature/{releaseName} branch back to the master and develop branch, tags the release with its name {releaseName}, removes the release branch, 
      1. git flow release finish {releaseName}
    2. Push master branch
      1. git checkout master
      2. git push origin master
    3. Push all your tags 
      1. git push --tags
      2. Alternative to push selected new tag: 
        1.  git tag -l 
        2. git push origin <tagname>
      3. Mark the release with that tag on github
    4. Test that pre-release Jenkins jobs work:
      1. https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20Plugin-DevEnv%20-%20pre-release/
      2. https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20Core%20-%20pre-release/
      3. https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20Plugins%20-%20pre-release/
    5. Test that travis jobs work
  9. Create release for Core, Plugins (repeat the sub-steps 8a-8e)
  10. Create debian packages for the release
    1. Adjust Jenkins tasks (see below) with the proper release branches and D-debian-package-version
      1. Core: https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Prepare%20packages%20for%20Core/configure
      2. Plugins: https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Prepare%20packages%20for%20Plugins/
    2. Run  https://ci2.semantic-web.at/view/UnifiedViews/job/UnifiedViews%20-%20debian%20-%20Prepare%20packages%20for%20Core/configure
      1. This also runs automatically creation of plugins.deb and publishes the artifacts to packages.unifiedviews.eu
  11. Test released packages
  12. Increase version of the develop branch 
    1. git checkout develop
    2. see How to adjust the versions
    3. git push origin develop

Note: Quick fix: 

commit change
git tag -d <tagname>
git push origin :refs/tags/<tagname>
git tag -a <tagname>git push origin master --tags

 

Adjusting versions when release is created 

When new release is prepared, the version of the artefacts must be adjusted.

For Plugins-devEnv: 

  • Run mvn versions:set -DnewVersion=2.1.5 at {root}/uv-pom
    • ? Then mvn versions:commit
      •  (Note: mvn versions:revert to revert unwanted changes)
  • Further changes: 
    • root/pom.xml  
      • increase version
    • uv-pom/pom.xml 
      • increase version
      • unifiedviews.api.version (cat */pom.xml | grep 2.0.0)
    • uv-dpu-template-base
      • pom.xml - increase version
      • src/main/resources/META-INF/maven/archetype-metadata.xml - unifiedviews_api_version
    • uv-pom-dpu/pom.xml
      • unifiedviews.helpers.dataunit.version, unifiedviews.helpers.dpu.version
      • ? unifiedviews.module-test.version (points to Core)
    • uv-dpu-helpers/pom.xml
      • unifiedviews.helpers.dataunit.version
  • Update parent versions:
    • Run mvn clean install on {root}
    • run mvn versions:update-parent -DallowSnapshots=false on {root}

  • Adjustments to the new develop branch
    • as above, just when updating parents allow snapshots

Core:

  • Run "mvn versions:set -DnewVersion=2.3.X" at {root}

  • Further changes:
    • root/pom.xml
      • adjust version - manually
      • adjust parent - uv-pom's version must be set to latest PDE release version 
      • uv-dpu-api-helpers.version
      • uv-dataunit-helpers.version
    • debian/pom.xml
      • adjust version - manually
      • debian-package-version
      • backend-version
  • Update parent versions
    • Run mvn clean install on {root}
    • run mvn versions:update-parent -DallowSnapshots=false on {root} and "debian"
  • Adjustments to the new develop branch
    • as above, just when updating parents allow snapshots

Plugins

  • Changes: 
    • upgrades version of root pom.xml
    • debian/pom.xml
      • parent version
      • debian-package-version
  • detect which plugins were changed. 
    • For the others, you may run to replace snapshot version with the previous non-snapshot version (e.g. 2.0.6-SNAPSHOT with 2.0.5) as there was no change and the version from previous release may be used.
    • You may run to decrease the version: 
      • For extractors: 
        • for f in e-*/pom.xml; do perl -pi -e 's/([0-9]\.[0-9]\.)([0-9])-SNAPSHOT/$1.($2-1)/e  if ($. > 10 && $. <= 25)' $f ; done
    • Check the changed versions !
    • For those which changed, please adjust the version manually. 
  • adjust also in debian/pom.xml
    • for f in debian/pom.xml; do perl -pi -e 's/([0-9]\.[0-9]\.)([0-9])-SNAPSHOT/$1.($2-1)/e ' $f ; done
  • check that all new DPUs are added in: 
  • check all versions in CHANGELOG are without "SNAPSHOT"
  • check that the refered version of UV API is NOT SNAPSHOT version
    • mvn versions:update-parent -DallowSnapshots=false

  • Adjustments to the new develop branch (after release is created) 
    • Adjust versions of plugins
      • for loaders e.g.:
        • for f in l-*/pom.xml; do perl -pi -e 's/([0-9]\.[0-9]\.)([0-9])/$1.($2+1). "-SNAPSHOT"/e  if ($. > 10 && $. <= 20)' $f ; done
    • Adjust versions in debian/pom.xml
      • for f in debian/pom.xml; do perl -pi -e 's/([0-9]\.[0-9]\.)([0-9])/$1.($2+1). "-SNAPSHOT"/e  if ($. > 22)' $f ; done

Notes: 

  • :%s/2.3.1/2.3.2-SNAPSHOT
  • Increase version for the plugins (if needed):
    • for all: ls -1 | while read line ; do ( cd $line ; mvn versions:set -DnewVersion=2.1.0-SNAPSHOT  )   ; done
  • Adjust parent for each plugin (to point to proper uv-pom-dpu in PDE)
    • mvn versions:update-parent -DallowSnapshots=true

    • ls -1 | while read line ; do ( cd $line ; mvn versions:update-parent -DallowSnapshots=true )   ; done
  • mvn release:update-versions 

Versioning strategy: 

  • Core and plugins-dev-env have a separate versioning strategy. 
  • Versioning of Plugins repository
    • When developer needs to change DPU, he will create a branch. Such branch is eventually merged to develop. When merging, DPU's version (major/minor/revision) must be increased. 
    • In develop, we use SNAPSHOT versions. 
    • When release is created for Plugins repository:
      • it contains all the currently available latest versions of DPUs (each DPU can have a different version)
      • if certain DPU was changed, its version is increased
      • If the DPU was not changes its version remained as in previous release
    • After releasing plugins, prepare the develop branch for the new release. Use SNAPSHOT versions. If the DPU changes (version in the release was update), update SNAPSHOT version. 
  • Pattern for versions: major.minor.patch (see http://semver.org/)
    • When there is a fix of certain feature, patch version should be increased 
    • When there is a new feature which is backward compatible, minor version should be increased
    • When there is a new feature, which is not backward compatible, new major version should come. 

 

 

Guidelines for Hotfix branches:

  1. Creates new hotfix branch hotfix/{version} based on the master branch and switches to that branch. {version} marks the new hotfix name.  
    1. git flow hotfix start {version} 

      1. optionally, you may supplement the command with a basename (release name) from which to start

  2. (Optional) If more internal contributors should collaborate on the hotfix, you need to publish the branch
    1. git flow hotfix publish {version}
  3. Work on that branch as needed
  4. Adjust the version number of the release & commit on that branch
    1. see How to adjust the versions
  5. Merges hotfix/{version} branch back to the master and develop branch, tags the release with its hotfix {version}, removes the branch, 
    1. git flow hotfix finish {version}
  6. Switch to master branch, push master branch
    1. git push origin master
  7. Push your tags 
    1. git push --tags

 

  • No labels