Differences between revisions 8 and 9
Revision 8 as of 2016-02-28 22:26:50
Size: 2110
Comment:
Revision 9 as of 2016-02-28 23:05:37
Size: 2524
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
do test rebuilds of all reverse-dependencies take notes of what breaks. do test rebuilds of all reverse-dependencies. take notes of what breaks, and report bugs with severity important.
Line 28: Line 28:
upload the new ruby-defaults to unstable. tell the release team that you intend to enable builds against the new ruby version in stable. provide information on which packages

wait for an ACK from the release team.

upload the new ruby-defaults to unstable and request binNMU of the packages that you know will build fine against the new ruby (and will not only build against the current default ruby)
Line 47: Line 51:
== phase 4: rebuild/fix after default is changed in unstable == tell the release team that you intend to switch the default and disable the old interpreter in unstable before doing it; wait for an ACK from them.
Line 49: Line 53:
packages get rebuilt/fixed to drop support for the old interpreter and/or build against the new default. request binNMUs for the packages that build against the default interpreter
Line 51: Line 55:
== phase 5: old interpreter gets removed == == phase 4: remove old interpreter ==

Ruby interpreter transitions

Ruby interpreter transitions are done in phases so that (hopefully) unstable is never broken:

phase 0: the new ruby reaches unstable

phase 1: enable both interpreters in experimental

ruby-defaults gets uploaded telling gem2deb to build for both the old and the new ruby versions.

changes needed in ruby-defaults:

  • edit ruby_debian_dev.rb and add a new has_support_for block for the new interpreter.

do test rebuilds of all reverse-dependencies. take notes of what breaks, and report bugs with severity important.

open a transition bug against release.debian.org. using the following parameters for ben (the transition tracker tool), where A.B is the old version, and X.Y is the new one:

Affected: .depends ~ /rubyA.B | .depends ~ /rubyX.Y/
Good: .depends ~ /rubyX.Y/
Bad: .depends ~ /rubyA.B/ & !.depends ~ /rubyX.Y/

phase 2: enable both interpreters in unstable, rebuild/fix

tell the release team that you intend to enable builds against the new ruby version in stable. provide information on which packages

wait for an ACK from the release team.

upload the new ruby-defaults to unstable and request binNMU of the packages that you know will build fine against the new ruby (and will not only build against the current default ruby)

packages get rebuilt/fixed with support for both the old ruby and the new ruby

ideally, what needs to fixed has to be fixed in a way that it won't need to be fixed again in the next transition.

phase 3: new interpreter becomes the default, old one is disabled

changes needed in ruby-defaults:

  • edit ruby_debian_dev.rb and remove the has_support_for block for the old interpreter

  • run ./debian/newruby X.Y and it will replace the old version with the new one in several places in the package (where X.Y is the version of the new interpreter).

stage this in experimental first, ask ask people to test (at least in debian-ruby@lists.debian.org).

in special, test rebuilding all the stuff that links against the current default ruby version and make sure they can be binNMUed when the default really changes.

tell the release team that you intend to switch the default and disable the old interpreter in unstable before doing it; wait for an ACK from them.

request binNMUs for the packages that build against the default interpreter

phase 4: remove old interpreter

  • remove from testing first
  • remove from unstable later