Le Lundi, Mai 09, 2022 14:32 CEST, Pirate Praveen <prav...@onenetbeyond.org> a écrit: > > 2022, മേയ് 9 5:33:18 PM IST, Yadd <y...@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
