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:

---

• Check performance — Checked and filed Global aliases cause performance regression #728. Further discussion should happen there.

---

• feature/redrawhook breaks zsh-autosuggestions #579 Fix z-asug interoperability: zsh-syntax-highlighting interoperability: Please register zle-line-pre-redraw hooks zsh-autosuggestions#529
• Merge feature/redrawhook: redrawhook issues #245 Use zle-line-pre-redraw (the feature/redrawhook branch) #749
  • Triage widget-wrapping issues
  • Triage feature:redrawhook issues
• (nice to have) Merge Question: have the driver sourced in zsh emulation? #688 (comment)

---

• Send Support an 'owner' key in region_highlight. zsh#57 to zsh upstream — done.
• Merge our patch Avoid emptying the whole of region_highlight #418 (comment) that relies on it (fixes Doesn't work alongside zsh-syntax-highlight? okapia/zsh-viexchange#1 (comment)) — 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 Avoid emptying the whole of region_highlight #418 (comment).
• Review the changelog entry for Avoid emptying the whole of region_highlight #418 (it's right at the top of changelog)

---

• Merge Add comments for the platform dependency of the regex module #747

---

• (nice to have) Merge 'main': Highlight backslash escape sequences outside quotes. #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 Add comments for the platform dependency of the regex module #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 #747 (comment)?

[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.

[danielshahaf]

I'm afraid it took me almost a year to find out, but still:

With my downstream packager hat on, would it be possible for release tags to be PGP-signed going forward, please? release.md calls for signing tags, previous tags were signed (see below), and our packaging scripts rely on a tag's PGP signature for verifying the artifact we package for our users.

Thanks for everything, upstream :-)

$ git tag -v 0.8.0-alpha1-pre-redrawhook 
⋮
gpg: Good signature from "Daniel Shahaf" [unknown]
Primary key fingerprint: E966 46BE 08C0 AF0A A0F9  0788 A5FE EE3A C793 7444
     Subkey fingerprint: 6EB6 0B63 7CE5 ACBF 2449  A2DA DB27 E997 429A F20C
$ git tag -v 0.8.0 
⋮
error: no signature found