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

Re: RFC: pry 0.13.0 upload to experimental?





On Thu, Apr 2, 2020 at 3:20 pm, Utkarsh Gupta <utkarsh@debian.org> wrote:
Hi Praveen,

On Thu, Apr 2, 2020 at 11:54 AM Pirate Praveen <praveen@onenetbeyond.org> wrote:
 Did you also fix the two broken packages mentioned by Daniel ?

a) pry has "Breaks" for respective packages.
b) ruby-guard has been fixed and uploaded.
c) ruby-pry-byebug is fixed in the git repository. Waiting for your
ack to upload 3.9.0 (from 3.7.0) to unstable. Let me know if gitlab
works fine; if it does, I'll process the upload.

1. At least SemVer.org compliance should be assumed (even though many upstreams don't follow it and breaking changes are introduced in even security updates, for example rack 2.0.7 -> 2.0.8 is not compatible) 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). So in this case ruby-method-source and pry, 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). 2. When ruby-method-source was uploaded to unstable, there should be these steps, a) ideally fix pry along with ruby-method-source b) file a bug with severity important against pry and give sufficient time for pry maintainer to update. When ruby-method-source was uploaded the bug against pry should be raised to serious. And same process should be followed for pry as well. That is the heads up should be given by filing bugs before uploading to unstable. It is also helpful if some one has to fix it after a long time and many dependencies have changed. 3. In case of pry-byebug since it is only a minor update of an upstream with public API, we can assume it does not break and upload without coordination. If we are unlucky and something breaks, we can fix it later.

If we are not following these, things become much harder to fix later (we will have to track and test every dependency change that happened).



Reply to: