New release?

[vanillajonathan]

It has been quite a while since the last release.

I would like to request for there to be a new release.

In the future, perhaps releases could become a bit more frequent?

[cutelisp]

I would like to request for there to be a new release.

There is a milestone for 2.0.15.
Note:#2956 (comment) after 2.0.15 will maintainers have rights on micro org?

In the future, perhaps releases could become a bit more frequent?

This has been a frequent topic AFAICS. I am not aware of releasing process, but I wonder why are them so infrequently although there are so much commits? Is there a downside?

[dmaluka]

There is no releasing process, it's all chaotic.

Once @JoeKar is back from vacation, we might discuss making a new release soon.

There is a milestone for 2.0.15 with 2 open issues, yes. We can postpone (yet another time) fixing #2839. But #3700 we should fix before the release, since it's an actual regression introduced since 2.0.14.

[JoeKar]

We can postpone (yet another time) fixing #2839.

Yes, I think we can do this.

But #3700 we should fix before the release, since it's an actual regression introduced since 2.0.14.

👍

[usfbih8u]

I would like to ask @JoeKar and @dmaluka for an announcement and a "freeze period" of 1 or 2 weeks before the release (when the time comes) so users can test the nightly version to catch any possible regressions.

In the current release (2.0.14), I caught a regression that was a minor inconvenience for me, but given the slow release rate, any major regression would mean getting stuck in the current version for another year.

And thanks for maintaining the repo!

[dmaluka]

This issue is a regression introduced after v2.0.14, and not just some minor one but causing a crash. We don't want to deliberately break things for users.

That said, #3658 does more stuff than just fixing this issue, so if we factor out just the fix into a separate PR, we may merge it sooner. I don't know how easy that would be to do, and I suppose @matthias314 doesn't exactly have a shitload of free time (and neither does @JoeKar or myself). Your help with that is welcome if you want to speed up the release.

...BTW besides that, at least the PR #3618 from @Neko-Box-Coder was reviewed and seems good and ready for merging (modulo a very minor remark from @JoeKar) so we'd better merge it before the release?

Also for instance a simple PR #3790 from @cutelisp - we might basically replace it with my suggestion and merge it?

Also FWIW I had spent some time reviewing #3795 from @cutelisp which adds support for tab dragging with mouse, opening new tab on double click and closing a tab on middle click. It would be nice to have these new features in the next release... Unfortunately it is not quite ready to merge, as I found a number of bugs in it (including a crash).

Any other reviewed-but-still-not-merged PRs I forgot about?

[dmaluka]

That said, #3658 does more stuff than just fixing this issue, so if we factor out just the fix into a separate PR, we may merge it sooner.

Or perhaps it would be easier to just debug and fix the crash in #3700 ignoring the PR #3658... Again, everyone is welcome to do that.

[niten94]

I've created #3913 where I tried to include a part of #3658. Tests are still welcome.

That said, #3658 does more stuff than just fixing this issue, so if we factor out just the fix into a separate PR, we may merge it sooner.

Yes. Since it cannot be merged currently, I think the fix should be separated now.

Or perhaps it would be easier to just debug and fix the crash in #3700 ignoring the PR #3658... Again, everyone is welcome to do that.

I don't think there's other solutions: #3700 (comment)

[matthias314]

I've created a small PR that I think fixes #3700. See my latest posting for that issue.

[JoeKar]

Any other reviewed-but-still-not-merged PRs I forgot about?

Maybe #3910.
Unfortunately the "review:approved" filter doesn't include reviews done and approved by someone else then the maintainer.