Differences between revisions 15 and 16
Revision 15 as of 2018-12-11 07:31:37
Size: 3209
Editor: Praveen A
Revision 16 as of 2019-05-15 07:34:17
Size: 3210
Editor: Praveen A
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
  1. Step 1: Refresh patches that is needed for build (Gemfile changes)
  1. Step 2: Refresh patches for bundle install --local (install the newly built package to find out)
  1. Refresh patches that is needed for build (Gemfile changes/quilt push fails)
  1. Refresh patches for bundle install --local (install the newly built package to find out)

Role 1: Update packaging progress tracker page

  1. 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/.

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

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

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

  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 people.debian.org, 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 https://salsa.debian.org/ruby-team/meta 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.
  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
  4. Move to unstable with dependencies only in experimental (always use experimental, never directly upload to unstable) after testing the new version in experimental.