Ok, I’m gonna explain in detail my problems.
First of all, I use Linux. In Linux, atom doesn’t auto-update, so I cannot guarantee that I’ll jump from 1.1.0 to 1.1.1. So, most of the time, I’m jumping like 2 minor versions.
Two: http://blog.atom.io/2015/01/15/announcing-the-atom-1-api.html <-- this says that Atom uses Semantic Versioning beginning on 1.0 version. When I use Package Generator, it even adds the following information in my package.json:
"atom": ">=1.0.0 <2.0.0"
So, even package generator is expecting that Atom uses Semantic Versioning, and expecting no API changes till the 2.0 version. It is not. This is the case - I’m seeing a lot of api changes on 1.0, to 1.1, to 1.2. This includes:
- Simple thing that seems to be “forgotten”, like
atom.workspace.getActiveEditor (it should be
getActiveTextEditor, the old version was removed in some post 1.0 version)
- Things that are poorly documented and then changed (like
.then - I was stuck with
.promiseDispatch, and needed to get the value using
- Things that were not asynchronous, and began to be, breaking packages in strange ways.
Two of these things should be easy to solve (the last one, not so easy) - for instance, let’s see the case for
atom.workspace.open - it should return, somewhere in code:
promise = callOpenFileProcess()
promise.valueOf = ->
promise.then (value) ->
# code to make DeprecationCop warn that this is deprecated
promise.valueOf = -> value
promise.promiseDispatch = (fn) ->
# Code to make DeprecationCop warn that this is deprecated
promise.then -> fn()
Ok, I know this code is awkward. But this is the price of Semantic Versioning - it is not an easy task. The code above would need no changes in Changelog (except when making things that were synchronous to assynchronous, or other changes that are not reflected in the API but can cause package breaks), because DeprecationCop would warn me nice and clear when there’s something wrong with my package. When using the post 1.0 version of Atom, I have a feeling that I have a powerful weapon (deprecation cop) that was very useful in the past (pre-1.0 releases) but now it’s useless…
Furthermore, I would suggest is that Atom makes a pre-2.0 version - a beta release cycle where the API changes, in favor of better performance or better code. It would be the user’s choice to use it, and when using it, the user would expect some package breakage, in favor of a faster (and possibly more stable) editor. For the rest of users, we’ll use the oficial non-beta releases, where there’ll be no changes in APIs.
Now, the problems in the approach you show me:
- Like I said, everytime I update Atom, I update 2 minor versions. This means that if I’m going to check if there are API changes, I must go to the changelog file, check there. Then, check on each release page to see if there’s some API change that I remember using in one of my 5-6 packages. Then, I’ll go to the Atom Blog, and check there. Then, check changes in Electron API.
- Just for the record, I’ve checked on the releases page. In a simple search for promise and .open, I found no information that
atom.workspace.open has changed the kind of promise it returns. So, this would not help me.
- I know this may sound rude, but I don’t make money for package creation. I’m using Atom right now, in place of a faster editor (like Sublime Text) or a console-and-gui one (like Vim, neoVim, or Emacs) because it’s the best editor to create plugins. And, everytime I create a plugin, I spend time on it, and sometimes I could use this time to work on other projects. So, this is more than simply frustrating - it’s time and money-consuming, and it’s becoming unsustainable.
I hope the Atom team understands these concerns. As I told, it’s a great editor for writing packages - but, if mantaining these packages becomes too dificult, or if to update Atom I should check three or four diferent places to check if nothing will break, it’ll lose most of its power.