Closed Jermolene closed 5 years ago
I'll start with the German translation
To your note about performance regression (#3517)
The kin-filter PR has been updated, see #3511
Will #3461 make it to 5.1.18 ?
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?
@Jermolene see: de-DE prepare for 5.1.18 #3576
Thanks @pmario
@Jermolene https://tiddlywiki.com/prerelease/#TiddlyFox%20Apocalypse should be removed from the landing-tiddler HelloThere
Thanks @pmario good point
@Jermolene Update of Dutch translation can be found here: http://tw5dutch.tiddlyspot.com/
Hi @Jermolene, could we include the fix for wrong platform detection on Linux? #3495
Further, there are two small PR's for tag-icons:
<<contrastcolour>>
macroThe problem with popups that aren't cancelled when we focus an input that has its own popup while another popup is shown: #3490
Thanks @BurningTreeC I've merged #3495, #3447, #3448 and #3490
Thanks @Jermolene , that's great! Have you seen the fixes for the Tags not animating #3577 and the Open tab animations #3578 ?
Hi @BurningTreeC thanks, yes I'll look at those too. Just updating the release note.
This line in the listen command should specify "tiddlywiki"
as an additional argument.
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.
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.
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.
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?
@Jermolene I created a pull request with the relevant changes. https://github.com/Jermolene/TiddlyWiki5/pull/3592
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:
This release deserves a name like Tiddlertechnik Extension Set Fall 2018 🤓
@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
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 .
Update as of 3rd December 2018 -- the blockers to releasing v5.1.18 are:
Thanks @BurningTreeC has resolved #3596, so now it's just a matter of sorting out #3598, I'm hoping @EvanBalster can help.
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.
@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?
@morosanuae the regression is still under investigation.
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.
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!
@Jermolene ... 5.1.18 is released - grats! - imo this can be closed.
We're embarrassingly overdue in releasing v5.1.18. To make it happen quickly, I propose that we switch immediately to "release mode":
The tickets that need to be addressed before we can release v5.1.18
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:
3572 - Fixing sticky titles
3565 - Keyboard shortcuts for dropdowns
3546 - New escapecss filter
I'll update this post as new information comes in from the comments.