incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Furkan KAMACI <>
Subject Publising Wrong Distribution
Date Mon, 05 Aug 2019 10:51:26 GMT
Hi All,

One of the projects that I am mentoring has a situation needs to be
resolved. I've copied the case below. What do you think about it:

"I want to resolve this soon.

Again the issue is this:

I pushed a bad package.json (with ‘files’ field) file to our v2.0.1 RC1.
This escaped testing prior to VOTE for v2.0.1 because I was only testing
with 'npm install' from repo (takes files direct from repo) rather than
’npm pack’ + ’npm install’ (packages tarball as though it were pushed to
npm registry, then installs from tarball). After the VOTE passed, I
followed up on release procedures, and published v2.0.1 RC1 to npm as
flagon-userale v2.0.1. The resulting npm package in the registry did not
include critical artifacts and scripts (I tested again immediately after

There was no choice but to unpublish v2.0.1 from the npm registry. ‘latest’
is v2.0.0.

The issue at hand is that we cannot now republish to npm a version
2.0.1—the registry is immutable. We have to publish a package with a
different version number.

My question was whether there were any issues in bumping Apache Flagon
v2.0.1 to v2.0.2, release through Apache and push to npm as v2.0.2 to
synchronize semantic versioning between Apache dist/releases and npm.js. Or
whether this requires a new release VOTE.

The alternatives are:

1. Proceed with release of v2.0.1 (adding fixes to package.json), then wait
until next version 2.0.2 to publish to npm—I don’t like this because 2.0.1
is a security-related patch, which  fixes over 200 low-depth dependency
vulnerabilities. v2.0.2 should be ready in a week or two, still we lose
consumer confidence everyday we don’t address these vulnerabilities.

2. Release an unofficial v2.0.2 on npm then synchronize Apache and npm
releases at v2.0.3—I don’t like this at all.

I am looking for any thoughts on the cleanest way to do this and generally
what best practice is from an Apache voting perspective.

I have corrected the flaw in the current 2.0.1, and tested using npm pack.
This has been pushed to a new RC branch:"

Kind Regards,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message