Renaming a package


#1

Is there are a graceful way to rename a package?

When you rename a repository on GitHub, you automatically get a redirect from the old to the new. If I delete and re-create a package, though, I believe it’ll break apm upgrade for anyone who’s already installed it. What would be convenient is an apm rename command that:

  • Redirects the atom.io/packages entry;
  • Preserves download count; and
  • apm upgrade notices said redirect and picks up on the name change.

Change package name
#2

Redirecting packages so that apm upgrade works is a good idea.


#3

#4

I have read the issues on atom/apm and I still don’t understand what the apm publish --rename actually does. The help says it renames it in package.json and on atom.io, but what happens to all the packages installed on user’s systems?

I want to rename auto-host-markdown-image since it will soon do more than hosting. It was actually named badly from the beginning.

If users would be abandoned by renaming then I would instead create a new package and have the old package show a pop-up telling the user to get the new one. Maybe it could have a link to the new, or for extra credit, actually do the install when clicked. I know this would clear the download counters etc. on atom.io but that is less important than supporting the users.

Any advice?


#5

@thedaniel Does this do the right thing from @mark_hahn’s perspective?


#6

This is somewhat related to another question I’ve had on my mind. Would it be considered rude if an upgrade of a package caused a pop-up that listed the new features? I know I would appreciate it if all the packages I used would do this.

It would also be nice to have a page on atom.io that shows the changelog for a package. Then you could go to a package’s page at any time and link to the changes.


#7

A book that has been very influential for me in the way I work with, design and advocate for change in software is About Face: The Essentials of Interaction Design. From that book:

Considerate products don’t burden you with their personal problems

At a service desk, the agent is expected to keep mum about her problems and to show a reasonable interest in yours. It might not be fair to be so one-sided, but that’s the nature of the service business. An interactive product, too, should keep quiet about its problems and show interest in the people who use it. Because computers don’t have egos or tender sensibilities, they should be perfect in this role, but they typically behave the opposite way.

Software whines at us with error messages, interrupts us with confirmation dialog boxes, and brags to us with unnecessary notifiers (Document Successfully Saved! How nice for you, Mr. Software: Do you ever unsuccessfully save?).

I would definitely classify a pop-up notification of new features under “inconsiderate software” because you’re supplanting what the user considers important with what you consider important. What if I already looked at the CHANGELOG and that’s why I updated your package? Now I have to look at the list of new features again? What if I just want to update my packages and get some work done … oh, now I need to dismiss this pop-up? That’s a little irritating. Basically, if software is acting like a four-year-old (“MommyDaddyMommyDaddy! Look what I can do now!!!”) then, in my opinion, it should be changed to be more like a super-efficient personal assistant.

This is why I appreciate the way the Atom update systems work. There’s just a little icon in the corner … a box or a squirrel. Just a little, “I’ll leave this here for you Sir, you let me know when you’re ready.” Then I can decide when updating packages or Atom itself is important to me.

It’s another permutation of respecting the user’s time similar to the difference between how OS X and Windows handle system updates in this other topic:

Now, is there a more convenient way to let the user pull up the CHANGELOG of upgraded packages than navigating to the package in the Settings View and clicking the button? Could we make it so that the view of the CHANGELOG highlights the sections of the log that cover all the versions included in the upgrade (let’s say that I went from v1.5 to v1.7.8, it should highlight v1.5.1, v1.6.0, v1.6.1, v1.6.2, etc)? Definitely! I just disagree with forcing the user to make the decision when the package author wants them to rather than when the user wants to.


#8

Ok, I’ll copy that.

Edit: I mean I’ll put a little icon on the status bar for a limited time.

I’ll put a package that does this on my long to-do list. It will take some tricky parsing but it will be fun. I’ll show a list of all installed packages to choose from and then show the changelog.


#9

What would make your life easier is if there was a standardized CHANGELOG format … which you could facilitate by creating a package for package authors that creates this standardized format. It could parse the standard Git comments looking for signifiers of events like:

  • Merge pull request #15 from janey-jo/foobar
  • Fixes #12
  • etc

and add entries into the CHANGELOG for the package author. Then they can clean it up or add what they like. Perhaps even add a Git pre-commit hook to look for the apm message of Prepare x.y.z release and automatically add the section header in the CHANGELOG.


#10

That’s exactly why I wrote changelog-gen some time ago (sorry for the self-promotion).

I think we can assume safely that most markdown changelog files displays the version in a title and use lists for displaying the features and fixes of a given version.


#11

Nice! Totally missed that one. I’m going to add it right now.


#12

When you rename a package, the previous name redirects to the new one. Users are not lost, though the system only stores one name to redirect from, so if you rename your package more than once in a short period of time, you might drop some users.


#13

Great. Will they get upgrade notices from the new name?