Release 0.8.0?

[danielshahaf]

I wonder if we should release master as 0.8.0 so we can immediately after that merge redrawhook, which is overdue. Thoughts? How long should the pre-release freeze be (waiting for bug reports from users of HEAD)?

Does current master perform acceptably?

---

EDIT: Here's a list of some tasks; interdependent tasks are separated by rules:

---

• [x] Check performance — Checked and filed #728. Further discussion should happen there.

---

• [x] #579 Fix z-asug interoperability: https://github.com/zsh-users/zsh-autosuggestions/issues/529
• [x] Merge feature/redrawhook: #245 #749
  • [x] Triage widget-wrapping issues
  • [x] Triage feature:redrawhook issues
• [ ] (nice to have) Merge https://github.com/zsh-users/zsh-syntax-highlighting/issues/688#issuecomment-599104145

---

• [x] Send https://github.com/zsh-users/zsh/pull/57 to zsh upstream — done.
• [x] Merge our patch https://github.com/zsh-users/zsh-syntax-highlighting/issues/418#issuecomment-623054593 that relies on it (fixes https://github.com/okapia/zsh-viexchange/issues/1#issuecomment-623054765) — ~~postponed to 0.9.0 since it can't be released before the zsh patch is merged and released~~ — will be in 0.8.0 after all, see https://github.com/zsh-users/zsh-syntax-highlighting/issues/418#issuecomment-650142375.
• [ ] Review the changelog entry for #418 ~~(it's right at the top of changelog)~~

---

• [x] Merge #747

---

• [ ] (nice to have) Merge #706

[phy1729]

I had assumed redrawhook was getting merged this cycle. If memory serves it's ready for merge just wasn't because it was late in the 0.7.0 cycle. I can take another look tonight if you like,

[danielshahaf]

Could do it that way too. It's just there's a bunch of changes already in for days so I wondered whether to split the release cycle so as to get them out before destabilizing master again. Cheers

[danielshahaf]

For clarity, I'm not proposing any change to the schedule for merging and releasing redrawhook: the dates on which it will be merged and released don't depend on whether the merge will be preceded by a 0.8.0 tag.

[danielshahaf]

@phy1729 Is the next step to review performance of master, or to merge redrawhook, or to release and then merge redrawhook? Not trying to rehash; just not clear to me what we decided…

[phy1729]

I think redrawhook should be merged considering how many issues it solves. Not NACK'ing releasing 0.8.0 first (version numbers are cheap), but redrawhook has been waiting for a long time.

[danielshahaf]

I was going to just merge it (there's only a trivial conflict), but there's #579. Let's discuss there.

[danielshahaf]

Does current master perform acceptably?

There's a regression: #728.

[danielshahaf]

I'm going through the redrawhook issues now. Merging redrawhook fixes ~~at least seven~~ seventeen different bugs, so I'll probably tag a prerelease before merging it, so as to have a point of reference. Probably going to call it 0.8.0-beta1.

[danielshahaf]

After IRC discussion, called it 0.8.0-alpha1-pre-redrawhook. That's the tag to use for testing the memo= feature, too.

[danielshahaf]

redrawhook is merged.

[danielshahaf]

And the merge went well. I think we have two options:

• Review the milestone again, merge whatever is ready now (e.g., PR #747), release master as 0.8.0, and then move forward on everything else
• Delay the release until [some issues and/or PRs] are addressed.

@phy1729 WDYT?

[phy1729]

Should resolve #747 and may as well merge #706. After that I don't really mind releasing or delaying for other issues. As noted on #764 many users use master, but version numbers are cheap.

[jirutka]

It’s been two years, what’s the state? Are there some major problems in the master branch blocking new release?

[danielshahaf]

1. None of the maintainers use the releases. We run master.

2. There are is-at-least 5.8.1.1 calls in the code. We were thinking of bumping those to is-at-least 5.9.0.0 if we release before zsh does.

3. If there are any other blockers, they'd be filed in the issue tracker with the appropriate milestone. (Conversely, however, some of the issues in the milestone can be deferred to a future release.)

[danielshahaf]

@phy1729 Got a second to review the text proposed in https://github.com/zsh-users/zsh-syntax-highlighting/pull/747#issuecomment-671061349?

[phy1729]

Looks like the pcresyntax link can use https, but otherwise looks good.

Since upstream is talking about releasing 5.9 soon, I'd like to see where that lands prior to us releasing due to the is-at-least checks.

[danielshahaf]

Upstream doesn't yet have a release schedule or a todo list. In any case, how about we update changelog since the last tag? If we finish that before upstream releases, we can release HEAD as, say, 0.8.0-beta1.

[jirutka]

None of the maintainers use the releases. We run master.

This just goes to show that there is no reason not to release a new version right now.

There are is-at-least 5.8.1.1 calls in the code. We were thinking of bumping those to is-at-least 5.9.0.0 if we release before zsh does.

How does this block a new release of the plugin? Anyway, Zsh 5.9 has been already released.

Can you please explain how it makes sense to you to tag a version once every few years?

[dvzrv]

Hi! I package this project for Arch Linux. We are still shipping 0.7.1 as there has not been a release in three years. Can you please tag a new release?

None of the maintainers use the releases. We run master.

Well, thousands of users of downstream distributions rely on there being releases. It's perfectly fine if you as developers of this project run the latest commit on the default branch, just please don't make everyone else do that.

[danielshahaf]

Hi! I package this project for Arch Linux. We are still shipping 0.7.1 as there has not been a release in three years. Can you please tag a new release?

Nice to meet you, David. Tagging a release is on our todo list.

None of the maintainers use the releases. We run master.

Well, thousands of users of downstream distributions rely on there being releases. It's perfectly fine if you as developers of this project run the latest commit on the default branch, just please don't make everyone else do that.

It's good to know people actually use the releases, so thanks for the input.

We have no intention of making everyone else use master. I mean, it /is/ convenient that whenever a bug is committed it gets reported before the day is out (!), but it's also annoying that we can't really destabilize master when we want to make invasive changes, and in the end, we wrote the Makefile's "install" target for a reason. (And FWIW, I don't use master directly, as in source /path/to/git/z-sy-h.zsh; I run "make install" from my git worktree every so often, and run z-sy-h from the installed tree.)

If we tag a prerelease ("alpha" or "beta" or "rc" tag), would that help, as an interim measure until a final release? We may be able to do the former sooner than the latter.

[phy1729]

Master has been relatively stable for a while and I think the remaining items on the milestone are puntable. release.md lists checking is-at-least usages, for which I have the below diff. Unless I hear objections in the next day or two I'll try to release 0.8.0 (although I don't use GPG, so the release won't be signed).

diff --git a/zsh-syntax-highlighting.zsh b/zsh-syntax-highlighting.zsh
index 9f8fe48..4295c93 100644
--- a/zsh-syntax-highlighting.zsh
+++ b/zsh-syntax-highlighting.zsh
@@ -155,18 +155,7 @@ _zsh_highlight()
         # C structs, so that none of the previous case patterns will match.
         #
         # In either case, fall back to a version check.
-        #
-        # The memo= feature was added to zsh in commit zsh-5.8-172-gdd6e702ee.
-        # The version number at the time was 5.8.0.2-dev (see Config/version.mk).
-        # Therefore, on zsh master 5.8.0.3 and newer the memo= feature is available.
-        # However, there's also the zsh 5.8.1 release, which doesn't have the
-        # memo= feature.
-        #
-        # On zsh master 5.8.0.2 between the aforementioned commit and the
-        # first Config/version.mk bump after it (zsh-5.8-607-g75c1edde5, the
-        # bump to 5.8.1.1-dev following the backport to master of the bump
-        # to 5.8.1), this condition will false negative.
-        if is-at-least 5.8.1.1 $ZSH_VERSION.0.0; then
+        if is-at-least 5.9; then
           integer -gr zsh_highlight__memo_feature=1
         else
           integer -gr zsh_highlight__memo_feature=0
@@ -415,9 +404,7 @@ _zsh_highlight_call_widget()
 #    We check this with a plain version number check, since a functional check,
 #    as done by _zsh_highlight, can only be done from inside a widget
 #    function — a catch-22.
-#
-#    See _zsh_highlight for the magic version number.
-if is-at-least 5.8.1.1 $ZSH_VERSION.0.0 && _zsh_highlight__function_callable_p add-zle-hook-widget
+if is-at-least 5.9 && _zsh_highlight__function_callable_p add-zle-hook-widget
 then
   autoload -U add-zle-hook-widget
   _zsh_highlight__zle-line-finish() {

[ThinkChaos]

Hi, I don't mean to sound ungrateful, but it's been a month since the "next day or two" any chance we can get a release? :)

[phy1729]

Sorry, life happened and I wanted to be relatively available in case of issues post release, but I think I will be now, so 0.8.0 is tagged now!

[danielshahaf]

Sorry, life happened and I wanted to be relatively available in case of issues post release, but I think I will be now, so 0.8.0 is tagged now!

Thanks, Matthew.