Hi all, we are finally near the 5.0 GA release!

However before proceeding I would like to merge / fix the PRs and issues that are strictly related to Redis 5 and do not apply to Redis 4. Things that also apply to Redis 4 would just delay Redis 5, so it's useless to address them right now. In the next days I'm going to scan the issues and PRs looking for such issues, however if you have some preferred one, please add it here in the comments. Thanks!

Comment From: itamarhaber

@antirez this would be a good opp to test drive GitHub's Projects :)

Comment From: antirez

@itamarhaber I'll give it a try soon or later, but for now I'm more focused on closing Redis 5 GA with the normal workflow. Btw I've the feeling that the category of "bugs not applying to 4.0" is almost contained in the Streams related issues / PRs.

Comment From: oranagra

off the top of my head...

interfaces changes, that are better introduced with a mojor versioin: * #5159 * diskless slave?

bug fixes for things that are only in 5.0 and unstabe: * ✅ #5242 * ✅ #5392

Comment From: soloestoy

AFAIK these bug fixes should be considered:

  • ✅ #5392 is a critical bug which may lead to crash when loading data from AOF.

  • ✅ #5333 is about streams command flags in Lua script.

  • 5208 is about write command flags in Lua script.

  • ✅ #5210 may lead to segment fault.

  • ✅ #5201 fix transaction broken when loading data from AOF.

  • ✅ #5141 fix XTRIM and XADD with MAXLEN inconsistency.

  • ✅ #4804 avoid free client unexpectedly when reload & loadaof.

  • ✅ #5426 fix data inconsistency after aofrewrite.

  • ✅ #5437 some problems in XCLAIM.

And some other optimizations:

  • 5368 update evictionpool if needed to make eviction more accurate.

  • 5362 avoid memmove to optimize aof rewrite.

  • 4994 and #4848 about module system.

  • 4895 fix wrong random key for hset and add zadd test in redis-benchmark.

Comment From: antirez

Thanks @oranagra and @soloestoy I'll review the list before 5.0 GA.

Comment From: antirez

@oranagra I'm sure you did not mean #539, I wonder if it's jsut #5392 also reported by @soloestoy

Comment From: oranagra

yes, that's what I meant.. not sure how one char got deleted before I posted.

Comment From: antirez

@oranagra perfect, thank you for the quick ack!

Comment From: oranagra

5412 something which we discussed in the past, it's a complementary feature for the saving of LRU in the RDB. if you want it.

Comment From: soloestoy

Just append ✅ to the merged PRs.

Comment From: antirez

I think I merged all the bug fixes you provided, so releasing a new Redis 5 RC. In the next days I'll focus on the improvements PRs.

Comment From: soloestoy

Hi @antirez , there are three bug fixes PRs left #5333 #5208 #5426 without ✅ , about Lua and stream.

Comment From: antirez

Ok for now let's go forward with the latest RC and I can merge those other things easily tomorrow, even if there is to release another RC in two/three days is fine. Then 17th we'll have GA. Right now I've another problem that I'm starting to dislike a lot, and is about the radix tree to be completely Valgrind unfriendly. I may change it to no longer use unaligned accesses actually since the space saving is not very big. Too many false positives are making Redis hard to Valgrind.

Comment From: AngusP

✅ Hi @antirez bit of a newbie here, but seemingly #5415 is a ~bug~ unspecified behaviour in the new Modules API that looks as if could be quick to fix?

Comment From: antirez

Thanks @AngusP, checking

Comment From: antirez

Just to provide the final API for Streams there is finally to implement AUTO for XREADGROUP and XGROUP CREATE apparently... All the critical bug fixes not applying to also 4.0 are fixed now. We can't put everything together but looks like tomorrow we could go GA, even if it means that GA will contain a few changes operated in the latest days: something I don't like. So I wonder if others monitoring this issue believe that it's better to go for a new RC instead and postpone 1 week.

Comment From: halaei

For every software I am happy enough with it's current version, when a new version x.0.0 is released, my approach always is to wait for x.0.1, because people try x.0.0 more than any RC, hence more bugs will be found and fixed. Only once I was unhappy about a major release, but that was because I knew there were some bugs introduced in the version, but my communication with the developers was weak and they didn't payed enough attention.

So if no one claims a new bug is in the new version, please release 5.0.0 ASAP 😊 Thanks

Comment From: halaei

Just a reminder. I think there should be #define REDISMODULE_APIVER_2 2 or something like that in redismodule.h. Also maybe blocking api shouldn't be part of REDISMODULE_EXPERIMENTAL_API any more?

Comment From: soloestoy

For every software I am happy enough with it's current version, when a new version x.0.0 is released, my approach always is to wait for x.0.1, because people try x.0.0 more than any RC, hence more bugs will be found and fixed.

Good idea @halaei , I agree with that.

Comment From: antirez

Ok so today will be the big day :-). Btw no need to change the API version since we only made backward compatible changes to the modules.

Comment From: soloestoy

BTW, please check #5333 and #5208 @antirez , these two are about Lua and streams.

Comment From: antirez

One merged the other delayed since it applies to Redis 4 as well and requires more time.

Comment From: filipecosta90

requesting core team to close this given v5 was released and if any issue remains we can track it in projects/individually.