https://www.npmjs.com/package/sha3 now points to the `/twuni/sha3.js` repo
davidmurdoch opened this issue · comments
Looks it it happened in this commit: 6fe5d15#diff-b9cfc7f2cdf78a7f4b91a753d10865a2L17
Was this on purpose?
It's a legitimate commit + change, but the intention wasn't to make a hard switch. It's something I needed to do in order to explore CircleCI for this project (which requires administrative permissions I do not have in this org). This is still the repo for active development.
Thanks for catching this -- I'll push a patch update to fix.
@davidmurdoch Fixed in #57.
I feel like this warrants further context. Any change that unintentionally makes it into production deserves a retrospective.
Q. How did these changes make it into the v2.0.3 release?
A. The v2.0.3 release build was published from a local repo whose master branch was tracking the HEAD of the twuni/sha3.js repo, instead of the intended phusion/node-sha3 repo. The twuni/sha3.js was hard-forked from the phusion/node-sha3 repo at the v2.0.2 release in order to explore CircleCI integration.
Q. Why was the repo URL changed in the first place?
A. I needed org-level administrative permissions on the org in which the repo is hosted.
Q. Why are org-level administrative permissions necessary?
A. In order to build and use CircleCI orbs, a user must have org-level administrative privileges.
Q. Why are CircleCI orbs necessary?
A. An orb is a unit of reusable configuration for CircleCI builds. Without orbs, even projects with identical workflows would be unable to share/reuse a configuration.
Q. Why migrate to CircleCI at all?
A. This project has no issues with Travis CI of which I am aware, so a migration to another CI provider is certainly not necessary. Exploring alternatives to existing solutions, in general, can reveal optimizations, deficits, or even perspectives that can positively influence the direction of a project. CircleCI has a different approach to CI than Travis, so I was exploring how this project could benefit from the extensibility of a Docker-based CI provider, including potential build speed and publishing improvements.
TL;DR. I published the v2.0.3 release from a local build that was tracking against master of a hard-fork of this repo instead of this repo itself. The hard-fork was only created because exploring CI alternatives involves org-level administrative configuration changes and pull request workflows that would be too invasive to perform on the primary development repo. To prevent this from occurring in the future, I will log a task to automate the release process, ensuring the release build is created under the correct conditions.
Thanks for that retrospective, @canterberry!
off topic, but it might be beneficial if you tag the 1.x branch on npm.
TIL how to tag things on npm. For convenience and to better illustrate the difference between 1.x and 2.x, I've added the native tag. This will come in handy for future revisions, if any, to the 1.x branch.
@canterberry if I could give you an award for Best FOSS Maintainer I would! Thank you!