Release Plan Help

Last modified by Thomas Mortagne on 2024/01/03 09:29

Contains instructions to perform various release steps in the Release Plans.

Initial Backward Compatibility Check

This initial step checks if the previous release cycle, or more recent bugfix releases done since, have properly set the xwiki.compatibility.previous.version property in the top level POM of xwiki-commons (for the branch you are currently releasing).

For example, if the current release to be made is for 4.2-milestone-3 and, in the meanwhile, there have been released bugfix versions for 4.1 (4.1.4 being the latest released), you need to ensure that the value for xwiki.compatibility.previous.version is 4.1.4.

Verify JIRA issue

If there are opened JIRA issues for the version you are currently releasing (fixVersion is set to the current release), you have two options:

  1. The issue has no code committed yet (Commits tab shows nothing). In this case, you need to push the issue to the next development version. (e.g. fixVersion = 6.3-milestone-1 will be moved to fixVersion = 6.3-milestone-2)
  2. There is some code already committed (Commits tab is not empty). In this case, you need to contact the assigned developer of the issue and find out if the committed code is complete:
    1. If the code is complete, you can close the issue (or ask the dev to do it)
    2. If the code is not complete, you can close the issue and ask the dev to create a new issue for the remaining work to be done for the next version.

In all cases, all opened issues must be closed before the release can be done.

Verify issues with commits

Such open issues may exist because the wrong issue key was used when committing, the existing commits are just trying to fix a test or adding extra logging (and not affecting the runtime) while the problem has not been addressed, it's a commit in a feature branch, etc. You need to ignore these false positives and detect any issue that has actual work done on it that is relevant for this release, close it and assign it the correct fix version so that it's properly counted in the release notes.

Note: The JIRA query is not perfect yet as we cannot query on the commit update date. Thus FTM you'll need to review each issue listed and verify if the issue should be closed or if it's a false positive.

Log on Release machine

# Get on the maven CI master machine
me@home:~$ ssh [email protected]

# Get on the agent machine
maven@maven:~$ release

Set up your identity

The first time

  • Configure your Github profile to add the SSH key of the agent so that the commits can be pushed to Github with your user (To get the agent SSH key, do cat ~/.ssh/ To verify it works, do the following on the agent machine: ssh -T [email protected]. It should reply with Hi <your user id>! You've successfully authenticated, but GitHub does not provide shell access..
  • Create your own GPG key if you don't already have one: gpg --gen-key
  • Publish your public GPG key, if you have not already done so: gpg --keyserver hkp:// --send-key <keyID>
  • Import your GPG key:
    • On your local computer run: gpg --list-secret-keys
    • Export your key in a secret.key file: gpg --export-secret-keys «keyID» > secret.key where keyID is the hexadecimal string on the sec line (either 8 char long or 40 char long)
    • Copy the secret.key file to the agent machine (you may need to copy to first and then to agent-1-1)
      • From your local computer, upload the key to scp secret.key [email protected]:/home/maven
      • From (/home/maven): scp -i ~/.ssh/releaser_ssh secret.key [email protected]:/home/releaser/<yourname>.gpgkey (give it a name)
        • The key can be stored on the agent, since it's password protected, so that you don't have to upload it next time, and just re-import it.
        • TODO: find out how we can keep the keys imported and tell maven which one to use during the release.
      • Remove the key from after you have uploaded it to agent-1-1: rm secret.key
    • On the agent machine, run gpg --import <yourname>.gpgkey
  • You need to have a .gitconfig.<yourusername> file. You can do that by copying one of the existing gitconfig file
  • Make sure your gitconfig file has the key signingkey in the [user] section (the value is your key id which you can get with gpg --list-secret-keys).
  • Copy your .gitconfig.<yourusername> file as the main gitconfig file: cp .gitconfig.<yourusername> .gitconfig

The other times

  • Configure your Github profile to add the SSH key of the agent so that the commits can be pushed to Github with your user (To get the agent SSH key, do cat ~/.ssh/ To verify it works, do the following on the agent machine: ssh -T [email protected]. It should reply with Hi <your user id>! You've successfully authenticated, but GitHub does not provide shell access..
  • Make sure previous release manager did not left his GPG key
    gpg --delete-secret-and-public-keys $(gpg --list-secret-keys | grep ^sec -A 1 | tail -n 1 | awk '{ print $1 }')
  • Import your GPG key, run gpg --import <yourname>.gpgkey
    • If you did not leave your secret key file on the agent machine, you have to re-upload it (see The first time section above).
  • Copy your .gitconfig.<yourusername> file as the main gitconfig file: cp .gitconfig.<yourusername> .gitconfig

Update Release scripts

# Update the release script
hudsonagent@vagent-1-1-dev:~$ cd xwiki-dev-tools ; git pull --rebase ; cd ..

Do a git status to verify that there are not any committed but not pushed stuff lying around...

Update Translations

For a release candidate, the translations were already merged (when the Pull Requests were accepted) into the master branch which you have just forked.

For a final or bugfix version, there may be translations added since the RC or the previous final/bugfix that we need to integrate. Perform the following steps:

  • Move to xwiki-trunks:
    hudsonagent@vagent-1-1-dev:~$ cd releases/xwiki-trunks/
  • Run the update goal of the script with your branch (e.g. stable-10.5.x):
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ ~/xwiki-dev-tools/weblate-scripts/ update stable-10.5.x
  • Review the changes for anything amiss.
    • You need to go through each project (xwiki-commons, xwiki-rendering, xwiki-platform)
    • Do a git status to spot changes.
      • Do a git diff --cached
        and visually review modified translation keys and spot problems (like spam).

        Be very careful when you update translations because the new ones might concern new stuff introduced in the master branch. The issue is that the translations platform does not support branches (translations are coming from master). Also make sure that when wiki pages are updated and the XAR version is increased/new fields are introduced, the document version isn't increased beyond the version supported by the released version as this might produce warnings, otherwise (see XAR Module Specifications for the supported versions) - for example, in 13.10.x, the version should be 1.4 at most.

      • No need to do a git add at this point since it will be done for all projects below.
  • Push / commit the translation changes on the branch of the version you are releasing (e.g. stable-10.5.x):
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ ~/xwiki-dev-tools/weblate-scripts/ push stable-10.5.x

Compute list of updated languages

Collect the list of updated languages to publish in the Release Notes:

  • cd to each repository (xwiki-commons, xwiki-rendering, xwiki-platform)
  • Run the script to list all relevant modified translation files since the previously released final version and generate the list of modified languages (notice the usage of the --diff parameter to help you decide if a translation language should be counted or not, see below for more details):
    ## start_commit end_commit [options]

    ## Example when releasing a final version (e.g. 10.7):
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-commons$ ~/xwiki-dev-tools/weblate-scripts/ xwiki-commons-10.6.1 stable-10.7.x --diff | less -r
    ## Example when releasing a RC version (e.g. 10.7RC1):
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-commons$ ~/xwiki-dev-tools/weblate-scripts/ xwiki-commons-10.6.1 xwiki-commons-10.7-rc-1 --diff | less -r

    ## Other examples on some already released versions (in case the need arises):
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-rendering$ ~/xwiki-dev-tools/weblate-scripts/ xwiki-rendering-10.3 xwiki-rendering-10.4 --diff | less -r
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-platform$ ~/xwiki-dev-tools/weblate-scripts/ xwiki-platform-10.3 xwiki-platform-10.4 --diff | less -r
  • Merge the list of updated language codes across all the repositories (from the output of the commands above) and update the Release Notes in the Translations section with these language codes.
    • Only count what should be counted:

      Be careful to only count real translation changes:

      • If Weblate reorder the translations but no new translation is added, the language should not be counted.
      • If a key is renamed (i.e. deprecated and a new one introduced with the same translation content), the language should not be counted. If the translation content has changed then the user will see something different and thus it counts as a language change.
      • <add more cases here as we find them>

      At the moment the script keeps all changes of the type `<start of line>key=value`, i.e. it discard comments for ex `#Missing someKey=someValue` is not counted.

      Since it can be hard to figure out what are user changes when there are key renames, key deletions or key move, another way to view changes is to look at the Activity Stream on l10n for added or changed translations.

    • Skip duplicates and sort the final list alphabetically.

If the flag for a translation is missing, add it to Language.

Build the release

Tip: running the release script will first ask you for your GPG key passphrase. If you mistype or enter a wrong passphrase, the release will fail to perform. You can test your passphrase locally running the following command :

echo "test" | gpg -o /dev/null --local-user <KEYID> -as - && echo "Passphrase is correct"

If for a reason or another you've made a mistake typing your passphrase in, you will need to delete (locally on the agent machine) the release branch and created tag before you can start over again.

In general the answer to What is the next SNAPSHOT version? is <next version in that branch>-SNAPSHOT and what is proposed is supposed to be correct already but it's still good to make sure it's really the case (and report it as a bug if it's not the case). Here are some examples:

  • when releasing 16.0.0-rc-1 the answer is 16.0.0-SNAPSHOT
  • when releasing 16.0.0 the answer is 16.0.1-SNAPSHOT
  • when releasing 16.0.1 the answer is 16.0.2-SNAPSHOT

If you have created the stable branch and are asked What is the next master version?, the version should be incremented (i.e. when releasing 16.0.0-rc-1 the suggestion should be 16.1.0-SNAPSHOT and when releasing 16.10.0-rc-1 the suggestion should be 17.0.0-SNAPSHOT) so that the master branch can move to the next development version.

Tip: Because the build process is a lenghty one (currently around 2 hours), it is a good idea to use the screen linux command. This is most helpful in case your Internet connection or electrical power drops. However, it is not in any way mandatory to use screen during the release.

# Perform the release from the release sources
hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ ~/

Restart the release

If the build failed or if you wish to release again, perform the following steps:

  • Set the version that you're building, e.g. hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ export VERSION='4.2-milestone-3'
  • Navigate to the repositories that failed to build (e.g. xwiki-platform) and clean up. For example for xwiki-platform:
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ cd xwiki-platform
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-platform$ ~/
  • Edit the script and comment out the previously successfully released repositories so that you don't release them again.
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-platform$ cd ..
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ vim ~/

    Go to the end of the file and scroll up, until you reach this section:

    # Wrapper function that calls release_project for each XWiki project in order: commons, rendering, platform, enterprise, manager.
    # This is the main function that is called when running the script.
    function release_all() {

    Inside this method, comment out the previously successful top level projects and leave uncommented the top level projects that still need to be released, including the one we are resuming from. In this example, we are resuming from xwiki-platform but xwiki-commons and xwiki-rendering were already successfully released, so we are skipping them:

     echo              "*****************************"
     echo -e "\033[1;32m    Releasing xwiki-commons\033[0m"
     echo              "*****************************"
    #  release_project xwiki-commons
     echo              "*****************************"
     echo -e "\033[1;32m    Releasing xwiki-rendering\033[0m"
     echo              "*****************************"
    #  release_project xwiki-rendering
     echo              "*****************************"
     echo -e "\033[1;32m    Releasing xwiki-platform\033[0m"
     echo              "*****************************"
      release_project xwiki-platform
  • Fix the build if need be (you won't need to fix anything if you just want to release again for example).
  • Re-launch the script from /releases/xwiki-trunks to resume from where we left off:
    hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ ~/

If the release:prepare is good and you need to restart only the release:perform

The instructions below are not applicable for RC releases (that involve working with other branches than master and other additional operations). Would need additional steps to be complete, so it`s safer to just restart from the top level project that failed (i.e. rendering, platform, etc.).

Going even further with the resuming of a failed build, in the case of release:perform, we can resume from the actual failed module. To do so, we must make some additional temporary modifications to the release script, besides the one described above which isolates the script to release only the currently failed module.

This method only applies to a single failed project at a time (e.g. xwiki-platform). Make sure all other projects are commented out in the release_all method.

Do not run the ~/ command on the failed module because release:perform needs that information to be able to resume. Also, remember to cleanup after finishing with the release of the project at hand.

Comment out the cleanup steps done in the release_project method:

 function release_project() {
  cd $1
#  pre_cleanup
#  update_sources
#  check_branch
#  create_release_branch
#  pre_update_parent_versions

Comment out the release:prepare step in the release_maven method and add the -rf group:artefactId parameter inside the -Darguments="..." with the module you want to resume the release from. See an example below where we are resuming from org.xwiki.platform:xwiki-platform-distribution-war.

function release_maven() {

 echo -e "\033[0;32m* release:prepare\033[0m"
# mvn release:prepare -DpushChanges=false -DlocalCheckout=true -DreleaseVersion=${VERSION} -DdevelopmentVersion=${NEXT_SNAPSHOT_VERSION} -Dtag=${TAG_NAME} -DautoVersionSubmodules=true -Phsqldb,mysql,pgsql,derby,jetty,glassfish,legacy,integration-tests,office-tests,standalone -Darguments="-N ${TEST_SKIP}" ${TEST_SKIP} || exit -2

 echo -e "\033[0;32m* release:perform\033[0m"
  mvn release:perform -DpushChanges=false -DlocalCheckout=true -P${DB_PROFILE},jetty,legacy,integration-tests,office-tests,standalone ${TEST_SKIP} -Darguments="-P${DB_PROFILE},jetty,legacy,integration-tests,office-tests ${TEST_SKIP} -Dgpg.passphrase='${GPG_PASSPHRASE}' -Dxwiki.checkstyle.skip=true -rf org.xwiki.platform:xwiki-platform-distribution-war" -Dgpg.passphrase="${GPG_PASSPHRASE}" || exit -2

 echo -e "\033[0;32m* Creating GPG-signed tag\033[0m"

Manually set the git tag name that will be used for GPG signing:

## The format is MODULE_NAME-VERSION. Modify accordingly.
export TAG_NAME="xwiki-platform-8.3-milestone-2"

Run the release script to resume the release of the current project:

hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-platform$ ~/

Cleanup the release script by removing the temporary changes described in this section. This applies if you want to proceed to the next project (e.g. xwiki-enterprise) where the release needs to be executed properly.

Generate Code Contributors list

  • The following commands should be performed on the agent machine, after running the build (but can be run locally as well).
  • If you're releasing a final version, also include the contributors for the RC.
  • Automatically, on the agent:
    ## <start_version> <end_version>
    releaser@releaseagent-dev:~/releases/xwiki-trunks$ ~/xwiki-dev-tools/xwiki-release-scripts/ 10.4 10.5-rc-1
  • Manually (on the agent or locally, if the automatic option fails):
    • Collect the list of code contributors for this release by running the following command on each branch on each repository that has been released (xwiki-commons, xwiki-rendering, xwiki-platform):
      > git fetch --tags
      > git log --pretty=format:"%an" <previousTag>..<nextTag> | sort -u
      ## Example:
      > git log --pretty=format:"%an" xwiki-commons-10.4..xwiki-commons-10.5-rc1 | sort -u
      > git log --pretty=format:"%an" xwiki-rendering-10.4..xwiki-rendering-10.5-rc1 | sort -u
      > git log --pretty=format:"%an" xwiki-platform-10.4..xwiki-platform-10.5-rc1 | sort -u
      ## For **final versions**, always compare with the previous final, not with the previous RC:
      > git log --pretty=format:"%an" xwiki-platform-10.4..xwiki-platform-10.5 | sort -u
  • Try to remove duplicates and infrastructure users (like xwikirogci or XWiki) and sort alphabetically.
  • Update the Release Notes in the Credits section with the contributors list.

Handle Backward Compatibility Actions

Update Backward Compatibility in the release note

The Backward Compatibility report is automatically generated in the Release Notes page by the {{backwardCompatibilityReport134 version="<version>"/}} macro which does the following:

  • Gets the revapi ignores from the pom.xml of xwiki-commons, xwiki-rendering and xwiki-platform GitHub repositories and store them in an xobject in the Release Note page. If you wish to regenerate the content from GitHub just delete this xobject.
  • Displays the ignores

If the XWiki version released is < 13.4RC1 then you need to use the old macro: {{backwardCompatiblityReportXml version="<version>"/}}

Update the backward compatibility setup in the build

If you're releasing a final or bugfix, perform the following operations on the agent or on your local machine:

  • Automatically, on the agent:

    ## <new_version>
    releaser@releaseagent-dev:~/releases/xwiki-trunks$ ~/xwiki-dev-tools/xwiki-release-scripts/ 12.3
    Also update the [master] branch? (Only if new release version is 'bigger' than the existing one. Y for final, N for most bugfixes except bugfix of a very recent final) :
    • When asked Also update the [master] branch?, only answer y (yes) in one of these 2 cases, otherwise answer N (no):
      1. (common) if you are releasing a final version (e.g. 12.3, from stable-12.3.x that was recently created by the release candidate that was released 2 weeks ago) OR
      2. (less common) if you are releasing a bugfix version that would be "bigger" than any existing version (e.g. 12.3 was just released, or even 12.3-rc-1, however, a critical bug was discovered and we quickly release the bugfix version 12.3.1. For this bugfix, you also need to update master, because it acts more like a final version than a bugfix and is 'bigger' than what was released until then.)
    • If releasing a final version and while waiting for this bug to be fixed, review the master branch for any Revapi ignore that would have been added after the RC release and removed by the script. If there's any, put them back.
  • Manually (on the agent or locally, if the automatic option fails):
    • Checkout master for xwiki-commons and edit the top level pom.xml to update the xwiki.compatibility.previous.version. Set the value to be your release you've just done.
      ## Replace the previous version with the new version (e.g. 10.4 with 10.5).
      hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-commons$ git checkout master
      hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-commons$ sed -i 's/<xwiki.compatibility.previous.version>.*</<xwiki.compatibility.previous.version>10.5</' pom.xml
      ## Double check that it has been updated
      hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-commons$ git diff
      ## Commit and push
      hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-commons$ git commit -a -m "[release] Updated compatibility previous version to the one just released."
      hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks/xwiki-commons$ git push origin master
    • On master, you have to remove ignores from 3 locations and then commit & push the changes (git commit -a -m "[Misc] Removed revapi ignores from the previous version"):
      • xwiki-commons/xwiki-commons-core/pom.xml
      • xwiki-rendering/pom.xml
      • xwiki-platform/xwiki-platform-core/pom.xml
      • If you are doing this on the agent, you can use nano to open the files and use CTRL+W to search for revapi. Once you have found the JSON formatted ignores, select all the lines you want to delete by using CTRL+SHIFT+6 and press CTRL+K to delete the selected lines. Exit the exitor with CTRL+X, y, ENTER (when asked if the changes should be saved) and commit the changes for each repository.
    • Make sure the xwiki.compatibility.previous.version value is changed also on the branch from where you've released, and that the ignores are cleaned too from the branch, since future releases (ex. 10.5.1) are final releases too.

Clean up identity

# Git identity
hudsonagent@vagent-1-1-dev:~/releases/xwiki-trunks$ cd
hudsonagent@vagent-1-1-dev:~$ cp .gitconfig.default .gitconfig

# GPG key
hudsonagent@vagent-1-1-dev:~$ gpg --delete-secret-and-public-keys $(gpg --list-secret-keys | grep ^sec -A 1 | tail -n 1 | awk '{ print $1 }')

# Local changes to the release-scripts (, user/password in, etc.)
hudsonagent@vagent-1-1-dev:~$ cd xwiki-dev-tools
# Double check that you are not removing any improvement you have made to the release scripts that should be committed instead ;)
hudsonagent@vagent-1-1-dev:~/xwiki-dev-tools$ git status
hudsonagent@vagent-1-1-dev:~/xwiki-dev-tools$ git diff
hudsonagent@vagent-1-1-dev:~/xwiki-dev-tools$ git checkout .

error Then don't forget to remove the Agent's SSH Key from your Github Account.

Blog post on

Create a new blog post on Example content:

  • Page name: XWiki153Released (for good SEO, i.e. without special characters that would be URL-encoded)
  • Blog title: XWiki 15.3 Released
  • Blog full content:
    The XWiki development team is proud to announce the availability of [[XWiki 15.3>>doc:xwiki:ReleaseNotes.Data.XWiki.15\.3.WebHome]].

    This release includes an improvement to the wiki macro parameter suggestions in CKEditor. It also includes some admin and developer enhancements, as well as accessibility improvements. In addition to these features, it also includes a number of bug fixes and some security fixes.

    See the [[release notes>>doc:xwiki:ReleaseNotes.Data.XWiki.15\.3.WebHome]] for more information.
  • Blog extract content:
    The XWiki development team is proud to announce the availability of [[XWiki 15.3>>doc:xwiki:ReleaseNotes.Data.XWiki.15\.3.WebHome]]. This release includes an improvement to the wiki macro parameter suggestions in CKEditor. It also includes some admin and developer enhancements, as well as accessibility improvements. In addition to these features, it also includes a number of bug fixes and some security fixes. See the [[release notes>>doc:xwiki:ReleaseNotes.Data.XWiki.15\.3.WebHome]] for more information.
  • Blog Categories: Releases. If releasing a bugfix version or a final version, also add What's New for XWiki and What's New for XWiki: Admin User.

Update is different from You can not simply edit the XWiki page and update the version value (or a special template page like it is done for en). Instead, you need to press the "pencil" icon next to the version value and be redirected to, the site that manages the data displayed by the infobox. There, you need to:

  • Add a new version entry to the existing list ("+ ajouter une valeur" button at the end of the list)
  • Enter the version number
  • Press "+ ajouter un qualificatif"
  • Type "date de publication" in the suggest box and select it.
  • On the right, type the release date in the format "26 janvier 2021"
  • Click on the control left to the version you have entered (the one with a small arrow pointing up) and select "Rang prefere". This will make it selected and displayed on the XWiki page.
  • Press "publier" to publish you new version
  • Click "modifier" for a version just before the one you have added that has the small arrow control pointing up.
  • Click on the arrow control and select "Rang normal". This will make it deselected so that it is not displayed on the XWiki page.
  • Check the XWiki page if the new version and date are properly displayed

Update Wikimatrix

This step must be performed only for the latest final releases (not bugfixes or RCs).

If it's the first time please register on and ask someone (Thomas for example) to get admin access to XWiki project for you.

Note: The only exception when a bugfix would be added here is when it would be done for the latest released final version (e.g. latest final is 10.2 and the bugfix is 10.2.1).

Forum Announcement

We no longer use the forum for news as we're now using exclusively the blog.

  • Add a new post to the users forum on
  • Example post:
    • Subject: XWiki <version> released
    • Content:
      The XWiki development team is proud to announce the availability of XWiki <version>.
      <short summary>

      You can download it here:

      Make sure to review the release notes:<short version>

      Thanks for your support
      -The XWiki dev team
    • Category: News & Events
    • Tags: release

Announce on Twitter

To announce the new release on X (Twitter), login to the`s account, since we don't have a CLI tool to automate the process. Use the following type of text:

#XWiki 8.4.1 has been #released! Check it out:

Announce on Mastodon

Announce the new release on Mastodon using Mastodon's account.
Currently, we don't have a CLI tool installed in the release matching to automate the process.

However, you can use toot, a nice CLI tool to interact with mastodon, on your own machine. To use it, proceed as follows:

  • Install toot
  • Add an account with toot login or use the right account with toot activate
  • Post with toot post "#XWiki 16.0 has been #released! Check it out:"

Rebuild Debian Distribution

The XWiki Debian distribution is automatically rebuilt every day using a crontab on

However, in order for the Debian distribution to be ready when we announce a new version, it's a good thing to force rebuild it.

This is achieved by logging on with the maven user and trigger a rebuild of the Debian index.

If the released version is starting a new LTS branch you will first need to update the script accordingly:

Run the script.

nohup /home/maven/ &

This start the index update in the background, you can leave.

Force Extensions Update

In order to have up to date versions on you should trigger the Batch importer scheduler (from the first node of the cluster).

Update Docker

This should be done only for final versions (i.e. includes bugfixes)

See documentation in the Docker GitHub project's README.

If you need help, ask Vincent emoticon_smile

Crash course on Docker:

Docker can create Images based on a Dockerfile (or a Compose file). Docker can also download Images from the DockerHub repository. Docker can create Containers from images. Docker also creates internal Volume unless you create mapped Volumes on your host computer so that you can navigate in them as local directories.

  • docker run creates a container locally based on an existing docker image.
  • docker ps lists the ids of running containers
  • docker ps -a lists the ids of all containers (running or not)
  • docker start <id> starts an existing container
  • docker stop <id> stop a running container
  • docker rm <id> removes an existing container
  • docker volume ls lists existing volumes
  • docker volume rm removes an existing volume
  • docker system prune removes unused data
  • docker network create creates a docker network so that several containers can see each other
  • docker network ls lists existing docker networks
  • docker network rm <id> removes an existing docker network
  • docker images lists all local images
  • docker rmi <id> removes an existing local image

Get Connected