[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Steps to follow to not break gitlab and diaspora when dependencies are updated



Hi,

Background: recent update of ruby-addressable broke gitlab.

https://ci.debian.net/data/packages/unstable/amd64/g/gitlab/latest-autopkgtest/log.gz

Could not find gem 'addressable (~> 2.3.8)' in any of the gem sources
listed in your Gemfile or available on this machine.

Reason: Declaring tight dependency by gitlab and diaspora.

Root cause: There is no guarantee that minor updates won't introduce
breaking changes.

Solution: Semantic Versioning.

Way out: We should follow these steps when either gitlab or diaspora
appears in the reverse dependency of any update.

    If it is a major version update, then it should be uploaded to
experimental first. Once compatibility with gitlab and diaspora is
tested, it can be uploaded to unstable after relaxing gem dependency in
their Gemfiles.

    If it is a minor version update and it is development version (>=
1.0), follow step 1 as there is no guarantee that minor versions will
not introduce breaking changes.

    If the gem follows SemVer.org, the upstream guarantees to not
introduce breaking changes in minor updates. Check list of upstreams
committed to semver first. If an upstream has not pledged SemVer
complaince, we should ask them to follow it and add it to the list.

    Check if the gitlab and diaspora versions in unstable allows the
minor update from "Packaging Progress Statistics" at
http://debian.fosscommunity.in/. If it allows the minor update (~> x.y),
upload the new version to unstable.
    If it does not allow, relax the dependency in Gemfile and request
upstream to relax the dependency so we don't have to maintain a patch.
gitlab has been responsive to such requests, but diaspora has not been.

I have documented these steps here
https://wiki.debian.org/Diaspora/Packaging/UpdateUpstream


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: