While this is 3.0.4, this is technically the first “stable” release for 3.0.4. While I find this kind of versioning inexplicable (I thought 3.0.0 was the stable release?), I hadn’t had any trouble with prior 3.0.x releases.
That’s not my understanding of semver? If this is the release, it should be 3.0.0 and prior ones should have been 3.0.0-rc.1 or 3.0.0-beta as per http://semver.org/#spec-item-9.
However, this is an end-user application and not a dependency, so perhaps there’s a different system being used.
Considering that semver mostly speaks about API, this is fine.
Prereleases often don’t include all APIs in a finished stage, so breakage between 3.0.0-pre1 and 3.0.0 are to be expected.
It’s completely valid, also in Semver, to say “this is, feature- and API-wise, our 3.0.0 but we give it 3 bugfix version before we call an official, announced release”.
It really bugs me that the iterm2 devs used a custom escape sequence for inline images instead of using libsixel. It’s fully-featured, well-tested, implemented in a variety of places, ANSI-compatible (unlike iTerm2’s implementation), and better standardized.
I have a large enough todo list as-is, honestly (and several of its items consist of adding sixel support to a couple other projects). But, that will take some time since I am not yet familiar with the internal workings of sixel itself.
EDIT: here’s hoping the issue that ngoldbaum posted below gets fixed and this proprietary escape is replaced by sixel/regis.
While this is 3.0.4, this is technically the first “stable” release for 3.0.4. While I find this kind of versioning inexplicable (I thought 3.0.0 was the stable release?), I hadn’t had any trouble with prior 3.0.x releases.
I’ve thought they’ve kept to semver, and that 3.0.4 is the first stable release in the 3.x series.
That’s not my understanding of semver? If this is the release, it should be 3.0.0 and prior ones should have been 3.0.0-rc.1 or 3.0.0-beta as per http://semver.org/#spec-item-9.
However, this is an end-user application and not a dependency, so perhaps there’s a different system being used.
Considering that semver mostly speaks about API, this is fine.
Prereleases often don’t include all APIs in a finished stage, so breakage between 3.0.0-pre1 and 3.0.0 are to be expected.
It’s completely valid, also in Semver, to say “this is, feature- and API-wise, our 3.0.0 but we give it 3 bugfix version before we call an official, announced release”.
The new shell integration features are super cool, but I had to move them out of my .bash_profile because they break emacs tramp-mode hard.
(So now I just source ~/.iterm2shellintegration.bash when I want/need it, thus leaving tramp working.)
It really bugs me that the iterm2 devs used a custom escape sequence for inline images instead of using libsixel. It’s fully-featured, well-tested, implemented in a variety of places, ANSI-compatible (unlike iTerm2’s implementation), and better standardized.
Don’t get me wrong, I suffer from NIH-syndrome as much as the next dev, but haven’t we done this enough?
I realize this isn’t always possible, but it’s open source. Have you considered contributing a patch?
I have a large enough todo list as-is, honestly (and several of its items consist of adding sixel support to a couple other projects). But, that will take some time since I am not yet familiar with the internal workings of sixel itself.
EDIT: here’s hoping the issue that ngoldbaum posted below gets fixed and this proprietary escape is replaced by sixel/regis.
There’s an open issue to support it in the next major release: https://gitlab.com/gnachman/iterm2/issues/3240