Role 1: Update packaging progress tracker page
Edit version in software.yml at https://gitlab.com/debian-ruby/gemdeps-generator. After committing the change, wait for the pipeline to finish (See https://gitlab.com/debian-ruby/gemdeps-generator/pipelines). The CI pipeline will generate a tracker page at http://debian.fosscommunity.in/.
Use Get ToDO list button of tracker to generate markdown formatted tracker, for example http://debian.fosscommunity.in/status/gitlab-v11.5.0/?type=todo will give a markdown version of gitlab 11.5.0
Create a new issue like https://git.fosscommunity.in/debian-ruby/TaskTracker/issues/100 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
Find if unpackaged dependencies are added in the new version (compare Gemfile of both versions) or use tracker at http://debian.fosscommunity.in/ For example, https://gitlab.com/gitlab-org/gitlab-ce/compare/v11.4.9...v11.5.3 has all the changes between gitlab 11.4.9 and 11.5.3 versions, search Gemfile to see the changes in Gemfile.
- 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 people.debian.org, or any personal site to host the repo.
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 https://salsa.debian.org/ruby-team/meta repo to automate this.
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
- 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.
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).
- Refresh patches that is needed for build (Gemfile changes/quilt push fails)
- Refresh patches for bundle install --local (install the newly built package to find out)
- 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).
- 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.
- Fork upstream code using web interface and clone your forked repo
- Create a new branch in your fork
- Update gem version in Gemfile
Run bundle update <gem name>
- Commit both Gemfile and Gemfile.lock
- Send merge request