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

Re: Change package source name



Le Lundi, Mai 09, 2022 14:32 CEST, Pirate Praveen <praveen@onenetbeyond.org> a écrit:
>
> 2022, മേയ് 9 5:33:18 PM IST, Yadd <yadd@debian.org>ൽ എഴുതി
> >On 09/05/2022 13:54, Yadd wrote:
> >>
> >>
> >> On 09/05/2022 12:56, Jonas Smedegaard wrote:
> >>> Quoting Yadd (2022-05-09 12:39:37)
> >>>> I just pushed to experimental node-regenerator (via NEW queue, thanks
> >>>> to ftpmasters!) which replaces two packages still existing in
> >>>> unstable: node-regenerator-runtime and node-regenerator-transform.
> >>>> These packages were downloaded from npm registry but the real source
> >>>> repository is node-regenerator which builds 4 packages.
> >>>>
> >>>> I also filed two BTS-ROM-RM against these two old packages.
> >>>>
> >>>> My question is about this transition. What is the process, wait for
> >>>> old packages removals then push node-regenerator to unstable or can I
> >>>> push directly node-regenerator to unstable?
> >>>>
> >>>> Note that node-regenerator-runtime and node-regenerator-transform have
> >>>> reverse dependencies (many via node-babel7...).
> >>>
> >>> Switching *source* package need no coordination.
> >
> >That's the goal of this discussion ;-) and that's the reason I pushed node-regenerator to experimental.
> >node-regenerator-* were not built from sources. src:node-regenerator builds those 2 packages and provides 2 new ones.
> >
> >>> Do you perhaps ask because at the same time you also bumped major
> >>> version of *binary* packages?  If that's the case then (independent of
> >>> the change of source package) those should be properly tested before
> >>> pusing to unstable, and any breaking changes should be coordinated with
> >>> affected reverse dependencies.
> >
> >There is no major update here, just an update from 0.13 to 0.15 (no changes for regenerator-runtime, little changes for regenerator-transform without any API changes).
> >
> Please at least assume compliance with semver.org which says 0.x version indicates development version and there is no guarantee minor versions don't break compatibility. So for 0.x version libraries even minor versions should be treated similar to major versions. Only when upstream has at least 1.0 release or higher we can assume backward compatible minor versions.
>
> So please test all reverse (build) dependencies and file bugs if any breaks, wait for at least 2 weeks to give time for fixes (or fix them) and then only upload to unstable.

As already said, there is no major changes here, and I know what to do to avoid regressions.
My question is about name conflict :
 * node-regenerator-runtime is provided by :
   - deprecated src:node-regenerator-runtime, badly downloaded from npm registry instead of real source (and then embeds some already packaged files)
   - new src:node-regenerator
 * same for node-regenerator-transform

Then, after all needed tests and no-regression tests and wait for 2 weeks and the sacrifice of a goat on a full moon night, what is the way to adopt :
 * wait for ROM-RM of old src packages and then upload new node-regenerator
 * upload new node-regenerator before ROM-RM
 * drop node-regerator and keep those old quick-and-dirty packages


Reply to: