Releasing v5.1.18

[Jermolene]

We're embarrassingly overdue in releasing v5.1.18. To make it happen quickly, I propose that we switch immediately to "release mode":

• Stop making changes to the code apart from fixes to regressions introduced in this release
• Getting as much integration testing done by the community as we can
• Polish the release note to make sure that all the amazing new features are discoverable and comprehensible

The tickets that need to be addressed before we can release v5.1.18

• About existing TOC vs. prerelease TOC performance degrading #3517 - Performance regression with table of contents macros

There are a couple of PRs that are being discussed at the moment that I don't propose to include in v5.1.18 because they introduce substantial changes and I think it will take us a little time to fully understand the impact:

• fix sticky titles - performant version #3572 - Fixing sticky titles
• [UI] add selectable tags- and search-dropdown #3565 - Keyboard shortcuts for dropdowns
• add escapecss filter #3546 - New escapecss filter

I'll update this post as new information comes in from the comments.

[pmario]

I'll start with the German translation

[BurningTreeC]

To your note about performance regression (#3517)

The kin-filter PR has been updated, see #3511

[BurningTreeC]

Will #3461 make it to 5.1.18 ?

[Jermolene]

Will #3461 make it to 5.1.18 ?

There's a lot in there, and so I'd be inclined to leave it until 5.1.19. But maybe there's some smaller chunks that are worth bringing forwards?

[pmario]

@Jermolene see: de-DE prepare for 5.1.18 #3576

[Jermolene]

Thanks @pmario

[pmario]

@Jermolene https://tiddlywiki.com/prerelease/#TiddlyFox%20Apocalypse should be removed from the landing-tiddler HelloThere

[Jermolene]

Thanks @pmario good point

[gernert]

@Jermolene Update of Dutch translation can be found here: http://tw5dutch.tiddlyspot.com/

[BurningTreeC]

Hi @Jermolene, could we include the fix for wrong platform detection on Linux? #3495

[BurningTreeC]

Further, there are two small PR's for tag-icons:

• show tag-icons in tags edittemplate #3447 makes tag-icons show up in the EditTemplate
• make tag-icons use the tag-pill-styles #3448 makes tag-icons use the computed color by the <<contrastcolour>> macro

[BurningTreeC]

The problem with popups that aren't cancelled when we focus an input that has its own popup while another popup is shown: #3490

[Jermolene]

Thanks @BurningTreeC I've merged #3495, #3447, #3448 and #3490

[BurningTreeC]

Thanks @Jermolene , that's great! Have you seen the fixes for the Tags not animating #3577 and the Open tab animations #3578 ?

[Jermolene]

Hi @BurningTreeC thanks, yes I'll look at those too. Just updating the release note.

[Arlen22]

This line in the listen command should specify "tiddlywiki" as an additional argument.

https://github.com/Jermolene/TiddlyWiki5/blob/19c49ae18a48a368ca24bb1493fc9876fa7c7570/core/modules/commands/listen.js#L42

This allows plugins to change their behaviour based on the server engine that is loading the data folder, as TiddlyServer sends an event emitter instead of the node server instance, and the Bob plugin may use this as well eventually.

I think it is better to get this in now rather than later in order to set a precedent.

[Arlen22]

Also, in https://github.com/Jermolene/TiddlyWiki5/blob/19c49ae18a48a368ca24bb1493fc9876fa7c7570/core/modules/server/server.js, HEAD requests should be given to the GET request handler since that is the way HEAD requests work.

[Arlen22]

Also, in https://github.com/Jermolene/TiddlyWiki5/blob/19c49ae18a48a368ca24bb1493fc9876fa7c7570/core/modules/server/server.js, HEAD requests should be given to the GET request handler since that is the way HEAD requests work.

At least that's what I think, but I guess that's open to discussion. A plugin needs to handle both with the same code usually, at least for the most part. I really think it would be an absolute pain to try to implement a separate handler for head requests.

[Jermolene]

Hi @Arlen22

At least that's what I think, but I guess that's open to discussion. A plugin needs to handle both with the same code usually, at least for the most part. I really think it would be an absolute pain to try to implement a separate handler for head requests.

It's a great point, and there would indeed be a simple implementation where we treat HEAD as GET but throw away the body. However, we don't handle HEAD requests today in v5.1.17 so it's not a regression, so I'm going to push that to 5.1.19 I'm afraid...

This line in the listen command should specify "tiddlywiki" as an additional argument.

That makes sense, would you be able to do a PR for the code change and docs?

[Arlen22]

@Jermolene I created a pull request with the relevant changes. #3592

[Jermolene]

Thanks everyone for your help. I think we've now dealt with the issues that have been raised since publicising the pre-release, with the exception of a few shortcomings with the comments plugin. I'm currently thinking of releasing v5.1.18 tomorrow, and dealing with improvements to the comments plugin for v5.1.19.

I've updated the prerelease to be up to date with the latest committed changes:

https://tiddlywiki.com/prerelease/

[BurningTreeC]

This release deserves a name like Tiddlertechnik Extension Set Fall 2018 🤓

[BurningTreeC]

@Jermolene , do you consider the tip, note and warning boxes #3317 for tw5.com? We don't have to like them, I just ask in case you've forgotten about them.

I've also added my very last PR - I promise - #3608 ... missing styling for the framed editor

[Jermolene]

Many thanks @BurningTreeC I was thinking of leaving #3317 but I'll have a look at it if I have time. I've merged #3608 .

[Jermolene]

Update as of 3rd December 2018 -- the blockers to releasing v5.1.18 are:

• Range operator #3598 - should we make further changes to the new range filter?
• style the framed editor #3596 - help needed in reverting the recent changes to the edit textarea (which were merged inadvertently)

[Jermolene]

Thanks @BurningTreeC has resolved #3596, so now it's just a matter of sorting out #3598, I'm hoping @EvanBalster can help.

[Jermolene]

Thanks everyone. I believe that now we just need to decide what to do about #3517 before the release. I'm inclined to leave it, and address any concerns in v5.1.19 but I'm open to the views of others.

[morosanuae]

@Jermolene, for me at least, it's not very clear what are the final conclusions of #3517. Is the performance degradation still in place with the same values @pmario have mentioned in the beginning?

[Jermolene]

@morosanuae the regression is still under investigation.

[Jermolene]

I've done some further tests for #3517 that do not show a significant performance regression, and so I'm going to proceed with the v5.1.18 release.

[kookma]

Thanks @BurningTreeC has resolved #3596, so now it's just a matter of sorting out #3598, I'm hoping @EvanBalster can help.

@Jermolene
Thank you Jeremy! Yes leave the range case #3598 for 5.1.19. There are different opinions about it!

[pmario]

@Jermolene ... 5.1.18 is released - grats! - imo this can be closed.