Deprecating packages?


#1

This topic is intended for discussing maybe a year or two down the road when atom has a stable package set and the excitement of developing new packages has died down a little bit.

Say I’m a package developer and I make a killer package that a lot of people like and use. I can manage pull requests and releases on Github, but what if I suddenly decide that Ruby is awesome and I hate Javascript and decide to stop developing the package? Say I want to let a prominent contributor have their fork be the “official” package repo so that current users don’t have to seek out the new package repo (or at least notify them that a new one exists). In this case, the official developer can mark his or her own package as “deprecated” perhaps with a link to the new one in package.json or similar.

Another situation would be if a package developer suddenly goes silent and no work is being done on an “official” repo, but a fork exists with more features and is actively being developed. How can users of the “dead” package learn of the newer, better supported one? In this case, marking packages as “deprecated” would have to come from the community (and could lead to issues should a developer come back and find their package no longer recognized as “official”)

Does atom provide a facet to manage these situations?

I’m not even sure if this is a major problem that should even be addressed, but I have personally experience similar issues using community extended programs (like Firefox, etc) where I’d go months or even years without knowing development for an outdated or incompatible addon was picked up by another developer.

Thanks for your time, all.


Will package names be cleaned in future?
#2

I think github has you covered in can se you want to transfer the ownership of the repo.


#3

Totally didn’t know you could do that in github. What about int the case where a package owner goes MIA? I understand forcibly transferring ownership of a repo is (probably) a very bad thing, but I’m particularly worried about packages that contain core features (perhaps from Sublime Text?) where many people develop now, but may no longer be supporting six years down the road. As a user I of course want features of my editor to be stable and supported. (Again, I’m not sure if there even is a good solution to this problem that balances the desires of both the users and the developers).

Thanks


#4

The standard solution for that is forking. Sure, you might have to name the package something slightly different, but are there package names that couldn’t possibly be replaced with something perhaps even better? I know my own tabs-to-spaces package should probably be renamed to something different now that it does tabs to spaces and spaces to tabs. I just haven’t bothered yet :blush: