Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Adding large new features here is strictly prohibited. 

 

Guideline:

...

  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

...

  1. see How to adjust the versions

...

  1. git flow release publish {releaseName}

...

  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

...

  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

...

  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/

...

  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/

...

  1. VirtualBox: https://docs.google.com/document/d/1SuCJsiu35ZTuhFBHO2c2B5t9xuGo5kDeaRmX2I5PoYI/edit

...

rm /etc/apt/sources.list.d/*

...

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

...

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

...

aptitude update

...

  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

...

  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

...

Note: To remove release branch not needed: git branch -D whatever/branch/you/wanna/delete

Quick fix: 

 

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

(Outdated) Testing Releases using EEA Jenkins jobs: 

  1. Core: Pre-release may be tested as follows (access to EEA VPN needed): 
    1. Adjust Jenkins task: http://ci.in.eea.sk/job/UnifiedViews-Core-debian/configure
      1. Branch: origin/release/UV_Core_v2.X.X
      2.  -Ddebian-package-version=2.X.X
    2. Run this task. 
  2. Plugins: 
    1. Adjust Jenkins task:  http://ci.in.eea.sk/view/OpenData.sk/job/UnifiedViews-Plugins-debian/configure to publish plugins to maven.eea.sk (they are available under: http://maven.eea.sk/artifactory/public/eu/unifiedviews/plugins/)
      1. Branch
      2. -Ddebian-package-version
    2. Run this task
  3. To publish Debian packages (Core + Plugin): Run the task: http://ci.in.eea.sk/job/unifiedviews-debian-packages-publish%20(prerelease)/
    1. Debian packages are available at: http://odn-ci.odn.in.eea.sk/prerelease/
    2. To install the Debian packages from pre-release location: 
      1. rm /etc/apt/sources.list.d/*

      2. echo "deb http://odn-ci.odn.in.eea.sk/prerelease/" wheezy main > /etc/apt/sources.list.d/odn-prerelease.list

      3. wget -O - http://odn-ci.odn.in.eea.sk/key/debian-odn.gpg.key | apt-key add -

      4. apt-get update

      5. Then you may follow: Installation Guide

 

See more details here: Releasing & Hotfixing UnifiedViews

Hotfix branches

Who may create such branches: Internal contributors, repository managers

...

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. 

Guideline: 

  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

See more details here: Releasing & Hotfixing UnifiedViews

Summary

 Summary of all types of introduced branches: 

...

When you build the develop branch (latest commit), the names of the created artifacts contains the information about the next planned major tag (version) and information that it is a working version (SNAPSHOT), e.g., commons-app-2.0-SNAPSHOT.jar, in case that the latest master version is >= 1.0.0 < 2.0.0 .  

TODO: Adjust pom.xml in develop branch

...

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
      • 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
      • :%s/2.3.1/2.3.2-SNAPSHOT

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 && $. <= 20)' $f ; done
    • Check the changed versions !
    • For those which changed, please adjust the version manually. 
    • NOTE: Check e-silkLinkek
  • 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

...

Notes: 

  • 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. 

 

 

Tests

 

The tests are located in java's common place. e.g /src/main/test/java/yourpackage

...