Sublime Forum

Best strategy to update Emmet plugin



I’ve developed a new Emmet plugin for some time and I’d like to to release it for all users. Since this is one of the most downloaded plugin for Sublime Text, I’d like to take advices from developers for the best upgrade strategy.

So far I have:

  • A new plugin repo.
  • A build step on CI, mostly used to download a single dependency (py-emmet) from PyPI. Build step then creates artifact with full plugin.
  • Tag-based release instead commit-based in old plugin: I’d like to inform users that new version is available and it provides new developer experience.

According to Package Control docs, switching repos should be an easy step. My main concern is a build step: I think Package Control will download source code for tag instead of artifact?

Also, if I switch to tag-based release, will Package Control show message for new release (defined in messages.json)?

Any advices on how to make it as smooth as possible for end-users?



By default Package Control just downloads the revision of the repository denoted by the most recent tag via<user>/<repo>/zip/<tag>

In order to use custom pre-built zip archives, you might need to provide a custom channel via globally available repository.json, which contains a list of all releases (as registry.json does). Its URL would need to be added to the channel.json and needs updates after each release. Maybe it should live in a custom repository your deploy script pushes the new release information to?

You could add this custom repository.json manually to see whether releases work before publishing to the global repository.

Maybe we can teach Package Control to download custom built artifacts from releases directly some day via:<user>/<repo>/releases/download/<tag>/<artifact>

The message.json mechanism is quite simple. This file just needs to be placed in the packages root. It contains a mapping of plain text files for each version (semver). The content of the text files are displayed if the plugin is installed or updated. GitGutter makes use of it, if you need examples. It is a good mechanism to display information about changes or new features.



Seems like updating channel.json should work for me: I already have custom channel which is used by beta users:
Its contents is updated after each release.

And my question about messages.json is whether it’s fine if package switches from commit-based releases to tag-based. Old Emmet package already uses messages and I was afraid that switching to tag-based release would suppress new message somehow.



Was not aware of latest to be available. Should work, yes.

The messages.json works the same way for tags. Just need to use the tag name as key instead of the built date.

   "install": "messages/install.txt",
   "0.4.1": "messages/0.4.1.txt"

You don’t need to add the v prefix, just the semver.



Just a note that the new plugin needs to have higher version than the old one for Package Control to upgrade to it.



Tried to send PR with new channel but got error from bot: seems like it can’t handle 302 redirects.