Is there going to be Releases for this repo in the future?

[HussainLatiff]

We are planning to use this library for a project and would like to know if this is going to be supported in the future since the last release is on August 2023? TIA

[ben-manes]

There are over 10 million unit tests with 99% code coverage. It is quite stable and questions are answered promptly.

I am not as active in making major changes so there is a bit of backlog work that I have not been able to get to. There have not been significant features or bug fixes implemented that deserve a new release. This project has limited scope and, in many respects, is complete.

As an open-source hobby project, support equates to the author's free time. I cannot promise to live forever, so you can make a guess about when support will end and if that's acceptable limitation.

[pobalopalous]

Since 2023 there were merges to the master branch though
e.g. #1478 and #1623 just as a sample.
Are you recommending that people use the released build and IFF they encounter an issue, then build from source locally to see if the issue is reproducible?

[ben-manes]

The vast majority of the changes on master were dependency updates, a rewrite of the build system, running static analysis tools on unit tests, and migration of nullability annotations. These were primarily for decompressing after work, given that I no longer write code in my role, so these were low-think efforts. Given that this project has always been weekend time, unrelated to any company, my own effort depends on motivation. If no one is motivated enough to contribute, per those issues you cited, then they linger as this is volunteer based.

Perhaps thanks to the holiday break, I felt more up to tackling those issues which is why they were resolved this week. #1623 only meant the entry could expire prematurely in the case of millisecond expiration and was found as the author was working on an internal kotlin adapter. #1478 is a real bug, but only when for an async cache in the oddball case of using refresh without an expiration policy. That ideally wouldn't be a configuration option and is typically a mistake, but was allowed in Guava and I didn't restrict focus on revisiting those decisions when working through such a large rewrite. Those two issues were open for nearly a year without anyone pushing for them to be resolved or offering to assist.

In terms of builds, we publish a maven -SNAPSHOT and allow for git hash versions via jitpack, so that one can easily fork + fix ahead of a release version. The usual process is that someone opens or adds onto an issue, we reproduce with a unit test, fix, and decide if a timely release is necessary. I was hoping to look at #1320 tonight and maybe cut a release this week after it bakes a bit. Most issues have been minor or questions, which are typically handled promptly.

I think this is all fairly reasonable. If you look at a company sponsored alternative, Ehcache, they have not released for longer than we have nor actively maintained their project in github. Sadly there is a hash flooding attack (aka HashDoS) that is quite severe and they have ignored it since disclosure against their 3.0-M4 pre-release. Using their latest, a simple workload trace takes 22.5 minutes whereas Caffeine or a LinkedHashMap LRU takes 7 seconds. The fix is a trivial change to their hash function because they lack a good hash distribution which is critical in their hash table modifications. I think that as an open volunteer project we've done better than a closed sponsored one that does not accept contributions from nor work with its community.

[ben-manes]

3.2.0 was released. I have no idea when or if there will be another release, because there is no obvious reason why that would be needed at this time.

[He-Pin]

Thank you very much , enjoy weekends