To me this is something that a changelog should clarify. SemVer is intended to be used by machines and a change in a major version should prompt a developer to take a look at the actual changes (i.e. the changelog) and whether they are affected by those.
Adding another number for this purpose still does not tell you whether your particular use case of a library received breaking changes or not.
Very exciting to finally see semver get some traction in one way or another! A very welcome decision and announcement, also supported by Haacked's post[1].
I have been quite active around the semver repo for a few years after 2.0.0 was released initially and participated in a lot of significant discussions that, to this day, still remain unresolved without either affinity to them or a stated rejection. After many years of seeing the same questions and suggestions pop up with no progress in sight, I just slowly lost hope and once issue updates started piling in to close issues at the initiative of @jwdonahue (thanks, by the way) without advancing any discussion or subject, I just unsubscribed. I am really exited about the things that are to come and will gladly try to participate in discussions to the best of my abilities.
Currently, there are quite a few things that SemVer needs to decide on (not necessarily implement), but imo the important points are:
1. How are versions selected? You mentioned this in the thread already, but this point is hugely lackluster about the current situation. See issue #205 for the biggest discussion to date and many cross-references.
1.1 Build metadata, especially in the context of version selectors, kind of "just exist". They serve mostly as a "catch all" for various things you might want to annotate a version, but there are no rules or use cases for them.
2. (Automatic) development/post-release builds come up frequently when trying to version snapshot builds, however Semver does not have a solution for this. See issue #200.
3. Clarify the "limbo" that are 0.x.y releases. To me, the spec is clear in its semantics for this, but the wording can be misleading to some. Basically, in the current situation semver just does not apply to 0.x releases at all (for the purpose of providing a "stable API") and this should be clearly communicated, especially for version selection.
4. Put more emphasis on what a "Public API" is, either in the spec itself or the FAQ. Many people have problems with this abstract concept and ask about it on the issue tracker.
5. Another topic that comes up frequently is demand for a "generation" or otherwise comparable fourth number to declare a kind of reboot for versioning. Some package managers have this (pacman, for example) and it is sparingly used, but there is no stance on whether or not SemVer would be interested in such an optional component or whether this is to be handled elsewhere. See issue #213.
You can ctrl+click to select two commits (from different branches) which are then diffed against each other. You cannot select branches in the sidebar directly like this, however.
I would keep an eye out on alacritty. It's a blazingly fast gpu-accelerared terminal emulator for Unix (currently) written in rust. According to their 0.2.0 announcement post, where they added scrollback support, Windows is next on the Roadmap.
There is more that goes into declaring a release as "stable" than just having it not crash.
For example, take the updated homepage, the licence upgrade process, the proper integration into linux package managers and more.
Couple that with the perception of users of things being "stable" having more reliability and them more likely trying it out and finding rare bugs or issues. Just looking at the forum today revealed a couple issues that nobody on the dev releases has discovered or reported.
That said, you still have to release a stable version every once in a while and they knew that. Unfortunately it took longer than anticipated.
To be honest, as a ST plugin developer, the underlying tech is very cool, except for JS/Coffee maybe.
You can do pretty much any UI you can imagine using a website in some way and Atom allows you to do exactly that. You can modify the entire UI and this is what I was always missing in ST: The ability to modify the UI more extensivly.
Sadly, this all leads to the very downside that everyone knows: Performance.
Computers will eventually get to the point where Atom feels as fast as Sublime, because
1) the coding was improved and more significantly, and
2) CPUs will get good enough for Atom that a human can't see differences between Atom and ST's performance, despite ST being way faster still. It's always been like that.
No, multicursors are way more powerful because you don't have to rename something in order to use them. The second animation on http://www.sublimetext.com/ is a use case that has occured several times to me alone, and there are more (e.g. indenting only specific lines, aligning code).
Except that, also for XChat, there will be people providing these binaries for free because the software is open source and they are not violating the license by redistribution for free.
[1]: https://www.sublimetext.com/3