We maintain a set of maintenance releases for TextGridLab 2.0
developbranch first, unless we are in a release phase (see below). Small issues can also be implemented first and
resolves #12345to automatically resolve the issue
references #12345to add a link between issue and commit in the issue tracker.
We use the git flow model (and the corresponding tools), or an approximation thereof: New development generally happens in the
develop branch, when we create a new release (e.g., 2.1), we fork a branch
release/2.1 off the
In preparation of the release candidate, it is best to work on the aggregate
textgrid-laboratory project to deal with all components (= submodules) in parallel.
git clone --recursive -b develop ssh://email@example.com/dariah-de/tg/textgrid-laboratory.git lab-3.3 cd lab-3.3 git checkout develop; git submodule foreach "git checkout develop" git flow init -d git flow release start 3.3 git submodule foreach "git flow init -d; git flow release start 3.3; :" $EDITOR .gitmodules # replace all branch=develop entries with branch=release/3.3 # e.g.: sed -i 's/branch = develop/branch = release\/3.3/g' .gitmodules git commit -am "Started release branch for 3.3"
release/3.3and checks it out
git submodule update --remotelater to get them to the tip of their branch
Now we should adjust the version numbers at the various places in the source code. Additionally, we should set the application name to "TextGridLab RC" to indicate it's a release candidate. There is a shell script in the textgridlab-modules project for that:
./set-version.sh 3.3.0 RC cd base git diff # possibly some '' are replaced with '', also there may be other unnecessary xml reformating # check the diff, undo unwanted things and commit git commit -am "Updated version information to 3.3.0 RC"
Publish the release branch:
git flow release publish 3.3 git submodule foreach "git flow release publish 3.3
Now Jenkins should start building RC on https://ci.de.dariah.eu/jenkins/view/TextGridLab/ and and a lab-3.3rc dir (updatesite) should show up in https://ci.de.dariah.eu/p2/ . It is possible that the order of the builds is not fine on first run, and triggers are failing. Try to get this fixed by: re-running the job 'lab-dependencies' in Jenkins. Trigger the "" button in Jenkins for builds without release-job. Fix the jenkins release build in future!
Once Jenkins is done the rc build pipeline should be in place.
After the build with all included releases has finished, the RC should be tested
When everything is tested we need to finish stuff in git, prepare the update site, upload the product zips and update the download website.
basemodule, update the update site enabledness state in
info.textgrid.lab.feature.base/p2.infto the following settings:
./set-version.sh 3.3.0to remove the 'Special Version' and generate the welcome screen look for the released version.
The git flow workflow's release finish feature performs the following steps:
These steps have to be performed in every submodule, then the
textgrid-laboratory module needs to be updated, then this needs to be released. If we're using an older working tree, we should make sure all branches are up-to-date:
git checkout develop; git pull git checkout master; git pull git checkout release/3.3 git submodule foreach " git checkout develop; git pull git checkout master; git pull git flow release finish -m 'TextGridLab 3.3' 3.3 : "
Now, we need to make sure the nightly branch does enable the nightly update site. To do so,
git checkout develop
info.textgrid.lab.feature.base/p2.infto enable the Nightly update site (two lines)
git checkout master
If everything above went cleanly, now push the submodules
git submodule foreach "git push origin master develop --tags; :"
Now commit the submodule updates in the
textgrid-laboratory module, still in the
release/3.3 branch, perform the release there, and push the master branch:
git submodule foreach "git checkout master; :" sed -i 's/branch = release\/3.3/branch = master/g' .gitmodules git commit -am "released submodules" git flow release finish -m 'TextGridLab 3.3' 3.3 git push origin master:master
The prerelease jenkins job should now build the actual release version off the master branches. Look into the dashboard, all release/3.3 branch builds should be gone, trigger a scan if not.
Wait for the final base build to finish and test it, and then go on to publish the released version.
/var/www/nginx-root/textgridlab.org/updates/stable. We have the following directory structure:
stable/composite/2.0.5 etc. each contain an update site for the respective version only.
stable/composite is an composite update site of all these version-specific update sites.
stable is a (non-composite) mirror of
To prepare this, there are a bunch of scripts linked to /usr/local/bin. Do the following, in this order, replacing 3.3.0 with the appropriate version:
generate-aggregate-repo https://ci.de.dariah.eu/p2/prerelease/base 3.3.0 – this will mirror the repository from the integration build to the directory
generate-composite-p2-repo "TextGridLab Stable" .* – this will create the composite repository metadata for the 2.* and 3.* subdirectories in the current (composite) directory.
generate-aggregate-repo $PWD/composite candidate – this will create an aggregate (= faster) mirror of the composite stuff in the
For each directory or file in
candidate, remove their respective counterpart from
stable and move the version from
candidate in place.
remove the (now empty)
composite*.xmlfiles are at Update Site Management.
/var/www/download. Files are in subdirectories with the version number
cd /var/www/nginx-root/textgridlab.org/download/ mkdir 3.3.0 && cd 3.3.0 wget https://ci.de.dariah.eu/jenkins/job/lab-base/job/master/lastSuccessfulBuild/artifact/*zip*/archive.zip unzip -j archive.zip rm archive.zip generate-lab-index.py --full > index.html generate-lab-index.py > fragment.html
/var/www/download/2.0.2and run the generate-lab-index.py script
According to the git-flow model, we have regular development in
develop and in
feature/xxx branches which get merged into
develop, release preparation branches called
release/<Version>, and a stable
master branch that features just the releases. Regular releases follow the following workflow:
develop → branch
develop → test & last bugfixes → release: (merge
master → tag master as
2.1 → merge master (or rather the tag) back into
develop (for each module, and for the umbrella project
However, it might be neccessary to apply just one or two bug fixes to the current release version and to publish the fixed version rather fast. To do so, git-flow supports the notion of hotfixes. Hotfixes branch off the latest released version (= master branch), perform the fixes, and then get merged into master as well as develop. Here it is explained for a case with a slight modification in the
base module (I forgot to disable the nightly update site for the 2.1 release):
git hotfix start 2.1.1 ( cd base; git hotfix start 2.1.1 ) ./set-version.sh 2.1.1 # updates the base module cd base git commit -a -m "Bumped version number to 2.1.1" # fix the bug git commit -a # useful bugfix message
Now you shoud cd up to the umbrella project, run
./build-locally to compile the fixed version, and test (the products can be found in subdirectories of
base/base-repository/target/products after the build). When everything is fine, you can release the hotfix, first in the submodule, then (commit the modified submodule first!) in the umbrella project.
cd base git flow hotfix finish 2.1.1 cd .. git commit -a # commit the updated submodule git flow hotfix finish 2.1.1
Now you need to push the changes:
git submodule foreach "git push --all; git push --tags" git push --all git push --tags
The prerelease build will build your hotfix. Afterwards, upload the hotfix release and update the update sites as described above.