when will Redis 6 for windows release?

[my9988]

i am looking forward redis 6 for windows,Thanks

[tporadowski]

I started porting 6.0 to Windows a couple of months ago, but got swamped in commercial side-projects. Hopefully I can get back to Redis for Windows in 2-3 weeks and first do a 5.0.12 update and then do a release of 6.0 within next 3 months.

[my9988]

Thank you very much

[zakeear]

I started porting 6.0 to Windows a couple of months ago, but got swamped in commercial side-projects. Hopefully I can get back to Redis for Windows in 2-3 weeks and first do a 5.0.12 update and then do a release of 6.0 within next 3 months.

Thank you very much

[XuJingJingZhenShuaiA]

Thank you very much

[ramlaxman]

I started porting 6.0 to Windows a couple of months ago, but got swamped in commercial side-projects. Hopefully I can get back to Redis for Windows in 2-3 weeks and first do a 5.0.12 update and then do a release of 6.0 within next 3 months.

Thank you for your efforts.

[xiaohanlaila]

I started porting 6.0 to Windows a couple of months ago, but got swamped in commercial side-projects. Hopefully I can get back to Redis for Windows in 2-3 weeks and first do a 5.0.12 update and then do a release of 6.0 within next 3 months.

Thank you for your efforts.

[sevenmostar]

I started porting 6.0 to Windows a couple of months ago, but got swamped in commercial side-projects. Hopefully I can get back to Redis for Windows in 2-3 weeks and first do a 5.0.12 update and then do a release of 6.0 within next 3 months.

Thank you very much !!!

[SamuelMarks]

@tporadowski What are the issues with the port? - Need a hand? - Many hands make light work!

[tporadowski]

@SamuelMarks it's very time consuming to go over file by file, then line by line in changed blocks. If the changes are straightforward then it's just a matter of hitting alt+arrow to copy them, otherwise they need to be adjusted to Windows, etc. And the issue is basically the lack of time :), although I've released 5.0.14 recently. Since Redis is already at 6.2.x, and my branch for Redis 6 was at 6.0.x - I was thinking of kind of starting it all over again to port 6.2.x - as then again - going through changes between 6.0 and 6.2 might be way too long... And yes, in this situation I would definitely need a hand! :). For this I've just created win-6.2 branch based on win-6.0 (which will be abandoned in the end). Let me know your thoughts!

[SamuelMarks]

@tporadowski It's been a while since Microsoft was on the scene… do you think it's worth reaching out to Redis and trying to contribute these changes back to their master, so we're not always playing catchup?

FYI: I'm working on https://github.com/offscale/version_redis and ensuring that Windows, macOS, FreeBSD, Linux, and SunOS targets can all work with the same library and CLI interface (mine).

[tporadowski]

@SamuelMarks they were never interested in maintaining a Windows port (neither Antirez, nor Redis Labs). There are also things like different data type models as described in src/Win32_Interop/win32_types_hiredis.h which are basically replacing e.g. each and every long long variables with PORT_LONGLONG definitions... I suppose it would have been different if those changes for Windows were minor and easy to maintain, but unfortunately they're not.

[oranagra]

@tporadowski can you satisfy my curiosity (and laziness or business to check for myself), and briefly describe the major changes / challenges? how does this port overcomes the lack of fork or other system APIs?

[tporadowski]

@oranagra I'm only continuing the work of MS Open Tech team (which either no longer exists or at least no longer maintains initial Microsoft port of Redis). Major changes are summarized by them as follows:

Windows-specific changes

• There is a replacement for the UNIX fork() API that simulates the copy-on-write behavior using a memory mapped file on 2.8. Version 3.0 is using a similar behavior but dropped the memory mapped file in favor of the system paging file.
• In 3.0 we switch the default memory allocator from dlmalloc to jemalloc that is supposed to do a better job at managing the heap fragmentation.
• Because Redis makes some assumptions about the values of file descriptors, we have built a virtual file descriptor mapping layer.

I would also add usage of I/O Completion Ports (IOCP) for handling networking.

There are some Windows-specific features as well:

• running Redis as a service and logging to Windows Event Log,
• disabling persistence via persistence-available config option,
• MSI installer.

The code in this port thus contains a fair amount of #if _WIN32 ... #else ... #endif blocks, exclusions via POSIX_ONLY() macro, replacements via IF_WIN32() macro, etc. Plus there are differences in data types (as mentioned above) which are "normalized" via PORT_* macros, different printf() placeholders, and so on. If all of that could be simplified and merged to Redis - then such places would have to be maintained/enhanced by people who know "both worlds" pretty well. Feasible, but I am unsure about "business justification" here ;) (although as you can see from the number of stars in this repo and some download statistics - there is interest in native Redis for Windows :) ).

[maxbad]

Thank you very much

Thank you very much

[xuyang60]

Thank you very much