Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2020-09-22 11:00:32
Size: 2119
Editor: Praveen A
Comment: create this page as copy of ruby teams policy
Revision 3 as of 2020-09-22 11:10:41
Size: 2147
Editor: Praveen A
Comment: add link to main packages page
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Read this [[/Teams/Ruby/Packaging/TransitionsPrimer|ruby team's transitions primer]] if you are new to handling transitions. Read this [[Teams/Ruby/Packaging/TransitionsPrimer|ruby team's transitions primer]] if you are new to handling transitions.
Line 13: Line 13:
Note: Bigger transitions like nodejs or babel may need collaboration from the whole team and new versions may be uploaded to unstable and broken packages may be fixed later. Try to coordinate with the team on the mailing list. Note: [[Javascript/Main/packages|Bigger transitions]] like nodejs or babel may need collaboration from the whole team and new versions may be uploaded to unstable and broken packages may be fixed later. Try to coordinate with the team on the mailing list.

Updating packages with API breaking changes

Read this ruby team's transitions primer if you are new to handling transitions.

At least https://SemVer.org compliance should be assumed as a compromise (as assuming every change breaks is not practical). This means major version updates of upstream with public API (when version >= 1.0) and minor updates of upstream without a public API (when version < 1.0). For example rollup update from 0.8 to 1.0 and browserify-lite update from 0.5 to 0.6, both are breaking changes (sometimes we may be lucky and nothing breaks, but we cannot assume that when upstream explicitly gives a warning by appropriate version bumps).

When uploading such API breaking changes these steps must be followed,

  1. Verify autopkgtests of all reverse dependencies and rebuilds of all reverse build dependencies are passing. Use Packaging/ruby-team-meta-build; or upload to experimental and watch the britney pseudo-excuses for experimental

  2. There are two paths you can take for uploading to unstable,
    1. Ideally all breaking packages should be fixed before uploading to unstable. Fixed packages should be uploaded along with the package that introduced API breakage.
    2. Upload to experimental and file bug reports with severity important against all failed packages. It is a good idea to document the list of packages that failed in debian/changelog. Give sufficient time for the maintainers (at least a week for simple fixes or more for complex changes) to fix the broken packages.
  3. When all the broken packages are fixed or the provided time is passed, upload to unstable along with all the fixed packages. Add Breaks for all the packages that failed. The bugs against unfixed packages should be raised to serious.

Note: Bigger transitions like nodejs or babel may need collaboration from the whole team and new versions may be uploaded to unstable and broken packages may be fixed later. Try to coordinate with the team on the mailing list.