Role 1: Update packaging progress tracker page

  1. Edit version in software.yml at After committing the change, wait for the pipeline to finish (See The CI pipeline will generate a tracker page at

  2. Use Get ToDO list button of tracker to generate markdown formatted tracker, for example will give a markdown version of gitlab 11.5.0

  3. Create a new issue like using the output from from previous step. Mention all members of debian-ruby team (@all), so everyone gets notified. Copy notes from previous version's tracker, if any. Note: For gitlab, we will also need to check these files GITALY_SERVER_VERSION, GITLAB_SHELL_VERSION, GITLAB_PAGES_VERSION, GITLAB_WORKHORSE_VERSION in the source tree and update packages.

Role 2: Update rubygem dependencies

  1. Find if unpackaged dependencies are added in the new version (compare Gemfile of both versions) or use tracker at For example, has all the changes between gitlab 11.4.9 and 11.5.3 versions, search Gemfile to see the changes in Gemfile.

  2. Optional: Package any new gems and add them to a staging repo until they clear NEW queue. Use reprepro package to create the repo. Use, or any personal site to host the repo.
  3. For stable libraries (?SemVer defines stable libraries as version >= 1.0), upload minor and patch updates to unstable directly (skip experimental) as previous version's Gemfile is already relaxed to allow newer minor versions. Check reverse dependencies are not broken when updating. Check the gemspec files of reverse dependencies for their exact requirement. Use build-and-upload script from repo to automate this.

  4. For major updates of stable libraries and minor update of development libraries (?SemVer defines version << 1 as development), use experimental as staging repo and upload all reverse dependencies to unstable together in a transition.

Role 3: Update the rails app

  1. Optional: Import the new upstream to a new branch (if the current version is still in experimental or if you think the update can take a long time to complete and you want to keep the previous version updated for bug fixes) and add package to staging repo. Note: Check debian/gbp.conf for any components listed, you will need devscripts >= 2.19.7~ for components support and some component tarballs may need to be manually created if uscan cannot download them automatically.

  2. Refresh patches to match versions in the archive. Relax stable libraries (>= 1.x) and be careful with development libraries (0.x). Update debian/control with stricter dependency for dependency update (it will help in backporting).

    1. Refresh patches that is needed for build (Gemfile changes/quilt push fails)
    2. Refresh patches for bundle install --local (install the newly built package to find out)
  3. Once new dependencies clear NEW queue, upload new package with dependencies to experimental. If the new version is a security release, embed the new dependencies to avoid waiting for clearing NEW queue. Remove the embedded copies when they clear NEW. You may also embed in case of transitions (for example rails).
  4. Move to unstable with dependencies only in experimental (always use experimental, never directly upload to unstable) after testing the new version in experimental.

Role 4: Keep dependencies in sync

If we have to update any dependency in debian first, go through the below steps to get it updated upstream as well.

  1. Fork upstream code using web interface and clone your forked repo
  2. Create a new branch in your fork
  3. Update gem version in Gemfile
  4. Run bundle update <gem name>

  5. Commit both Gemfile and Gemfile.lock
  6. Send merge request