4 ms·
I like this idea. Maybe you could even have a more fun variant where you add a random goofy adjective ("big" is unsuitable because it could mean something, but
by hnarn 9y ago
I like this idea. Maybe you could even have a more fun variant where you add a random goofy adjective ("big" is unsuitable because it could mean something, but "sparkly" hardly has bearing on a software package), or something else that is randomly assigned rather than propagating someone's user name. Sometimes it's a one man package but for a package with 300 contributors it doesn't make sense why someone's name should be slapped onto it forever.
- reificator 9y agoIf it's a package with 300 contributors you would use an organization's name, not a person's name.
- hnarn 9y agoOk, so what happens when the same package evolves from one person to a team of 300 people?
- reificator 9y agoThen you migrate. If the platform provides tools to do that, you use them. Otherwise you make a new namespace, upload the project to the new one, and edit the old one with a link to the new one and a deprecation warning. Then if you have a trusted announcement platform like a blog or Twitter, announce it there. If it's feasible to do so, you also push updates to both namespaces for a little while during the transition.
- always_good 9y agoAnd I think the package manager can do so much more here than current ones from a UX level. For example, instead of having to push updates to both packages, you push updates to the new one and, because you've annotated the old one with the move, users have a somewhat seamless experience when they run their update: they'll get a little heads up about the move, explain that oldpackage eol'd at 5.4 and newpackage picked up at 6.0, and would you like me auto-update your manifest? And/or the package manager supports a rename flow that does this for you.
- reificator 9y agoYeah, like I said, if the platform provides that kind of tooling, take advantage of it.
- always_good 9y agoI think a package manager should have first-class support for those sorts of governance changes because these structures change. For example, packages direct to their latest state. Trying to upgrade a package with an org change will explain this during your next update. Github has some good examples of this when repos change hands.