incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Publising Wrong Distribution
Date Mon, 05 Aug 2019 15:29:21 GMT
On Mon, Aug 5, 2019 at 6:52 AM Furkan KAMACI <> wrote:
> 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
> publishing).
> 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,
> Furkan KAMACI

npm and dist.a.o have the same problem - they are essentially immutable.

And there are good reasons for that, but that's beyond the scope.
Consider 2.0.1 a failed release, and start voting on a fixed 2.0.2
that is what 2.0.1 should have been and ship it.
Voting should be much faster this time around - and you get the bonus
of another thing that becomes obvious to check for.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message