Hi all,

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...).

Cheers,
Yadd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============@26762172940977687=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJ4808ACgkQLHwxRsGg ASGyFA//Z7+2quE4LTViWk9f0RfgkP8NVALdwseD1GI42drCT1xhE1PJv3WHYZgw pETie3tMFv3BO/Iuc5k+puG/+QbZ/7Z9NF3rbmzeJ1NCm0B2M/VjnHshIgUstJSu LbUyWsIxIraTNP9QQNFdc6C5oCDJfmUBYxRu8af3r/tghzD8z1mN9MSrnCP1OVTc u4/WWSsvksA/c/P5COz1dMATYC8yLONKYwjN+xTjFpAc/iVetLRWn+zUpskbkbTL QeM6QZXQQj7D2wifYTN7KWVVzZy3uKqju75/iGDD7PvBAino/zwPRrNKaJ9TEfUh xT7gbRPflqCwDsgA7p5nYvnBXyA4pAD/5TyHQPtjx3oc8Rf6s0lvEvdk3OBsdijT JkPC3zeLyn6Z5zmiQQqwm3YnYQ1rGfErLW9M3cA8fwy/BfmYkUzWhA4YGpqXZwlK aHwwcXKBs1MHQwDEIiGmgfOczCLp59ICTSZvDP6cYEcATQ9IspiHzrENvpJDjExN yXLyLkfmScDcQMjY/

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

Hi 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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Xjo4mVW0tzEILe13PCf0AW5n
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgWWFkZCwNCg0KT24gMDktMDUtMjAyMiAxNDo1NCwgWWFkZCB3cm90ZToNCj4gVGhlbiwg YWZ0ZXIgYWxsIG5lZWRlZCB0ZXN0cyBhbmQgbm8tcmVncmVzc2lvbiB0ZXN0cyBhbmQgd2Fp dCBmb3IgMiB3ZWVrcyBhbmQgdGhlIHNhY3JpZmljZSBvZiBhIGdvYXQgb24gYSBmdWxsIG1v b24gbmlnaHQsIHdoYXQgaXMgdGhlIHdheSB0byBhZG9wdCA6DQo+ICAgKiB3YWl0IGZvciBS T00tUk0gb2Ygb2xkIHNyYyBwYWNrYWdlcyBhbmQgdGhlbiB1cGxvYWQgbmV3IG5vZGUtcmVn ZW5lcmF0b3INCj4gICAqIHVwbG9hZCBuZXcgbm9kZS1yZWdlbmVyYXRvciBiZWZvcmUgUk9N LVJNDQoNCl4gVGhpcy4gSWYgYSBzb3VyY2UgQSB0YWtlcyBvdmVyIHRoZSBiaW5hcmllcyBv ZiBhbm90aGVyIHNvdXJjZSBCLCBhbmQgQiANCm5vIGxvbmdlciBidWlsZHMgYmluYXJpZXMs IGl0J3MgZGVjcnVmdGVkIGFuZCByZW1vdmVkIChhdCBsZWFzdCBJJ20gDQpjb25maWRlbnQg dGhpcyBoYXBwZW5zIGluIHRlc3RpbmcsIGxlc3MgY29uZmlkZW50IGFib3V0IHVuc3RhYmxl LCBidXQgYXQgDQpsZWFzdCB0aGUgdGFrZW92ZXIgaGFwcGVucykuIFRoaXMgb2J2aW91c2x5 IG9ubHkgd29ya3MgaWYgdGhlIHZlcnNpb25zIA0Kb2YgdGhlIGJpbmFyaWVzIGJ1aWxkIGJ5 IHNvdXJjZSBBIGFyZSBoaWdoZXIgdGhhbiB0aGUgdmVyc2lvbnMgb2YgdGhlIA0KYmluYXJp ZXMgb2Ygc291cmNlIEIuDQoNCj4gICAqIGRyb3Agbm9kZS1yZWdlcmF0b3IgYW5kIGtlZXAg dGhvc2Ugb2xkIHF1aWNrLWFuZC1kaXJ0eSBwYWNrYWdlcw0KDQpQYXVsDQpUaGFua3MgZm9y IHlvdXIgd29yayBpbiB0aGlzIHBhcnQgb2YgdGhlIGFyY2hpdmUuDQo=

--------------Xjo4mVW0tzEILe13PCf0AW5n--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmJ5eFYFAwAAAAAACgkQnFyZ6wW9dQqo ZAf+K5lnmBlmKJM/3eWIXd2Sa0Urs9GsmiTH+8mqyOC2YTWTAHzFnh1D/t2Oceda/RPVrMRyo0cC ihAWnP4myMskyGLavv5jR6G+yZ77q40EMZsU4jP+OaBS7poHHfWabVLagIiKOHz6QYJNi/9r8S4+ evveJ5Ny0jAc/TqVE9oZD6O756ir2HZ5bj7PFJBsTU3cRwpU6lpZcQz8MnRoT9BMqNxNtsdqaKzT XvoF2kOLEf3XJSdVUFa8Grc6k20FEkDwg6CJZ03tBhNRf1wADmSXfR1T2in97cpG/K9NBvkOxwKn J+HdbXH6CxVeqy32BvozePguuWrXOTIF7Z91HZ2w8w==
=+j8y
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/05/2022 22:23, Paul Gevers wrote:

Hi Yadd,

On 09-05-2022 14:54, Yadd wrote:

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

^ This. If a source A takes over the binaries of another source B, and B
no longer builds binaries, it's decrufted and removed (at least I'm
confident this happens in testing, less confident about unstable, but at least the takeover happens). This obviously only works if the versions
of the binaries build by source A are higher than the versions of the binaries of source B.

Perfect, many thanks Paul!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)