Redis is not shipped in EPEL9, because it's in RHEL9. Same with EPEL8 and RHEL8. It is shipped in EPEL7 at version 3.2, presumably because updating any further would be an incompatible update.
The license change announcement clearly states it will only be for 7.4 and up. The prior branches (6.2.x, 7.0.x, and 7.2.x) are still going to be maintained as per their security policy [0], and I haven't seen any indication that these maintenance updates will be anything other than BSD-3-Clause licensed. The license change commit has only occurred upstream in their unstable branch (future 7.4), and the 7.2 branch still has the previous license file [1]. This isn't like when mongodb switched to SSPL for all future versions, including maintenance/security updates to older branches. Considering these factors, F39+ can stay on 7.2.x for quite some time. F38 can stay on 7.0.x for the rest of its lifecycle. The only thing we can't do is update any branch to 7.4.x. Having keydb obsolete redis in Fedora would not be appropriate in my opinion, because they are still different software, and a user may want to have both installed at the same time. Additionally, keydb in EPEL definitely can't obsolete redis in RHEL. Maybe at some point we'll go the obsolete route in Fedora with a change proposal and FESCo approval, but I don't think we're at that point yet. [0] https://github.com/redis/redis/security/policy [1] https://github.com/redis/redis/blob/7.2/COPYING On Thu, Mar 21, 2024 at 1:19 PM Scott Williams <vwfoxg...@gmail.com> wrote: > > Redis-6 is currently shipped in EPEL9, so it seems like a more obvious > step-forward wrt EPEL. > > > > Honestly trying to replace redis with KeyDB in Fedora would be a step > > backwards and cause headaches so I don't think it's feasible, at least > > until redis v7 features are merged into KeyDB. > > Unfortunately, it's still the best option we have. Ideally, redis wouldn't > have done this, but since redis is no longer license compatible, can we > really continue to ship redis-7 in Fedora 40 if we can't patch and maintain > it? If KeyDB were to merge and release a v7 version against the latest BSD > code, I agree that it would be a much better target for Fedora 40. > Unfortunately, we're in the awful position of having to choose between a > breaking change for a small amount of users or shipping something that we > can't patch or realistically maintain. If we have some clue that a v7 > merge/release is on the very near horizon for KeyDB, then maybe it makes > sense to keep redis and obsolete it for KeyDB after GA, but it would be > preferable, IMO, to have a clean break on Fedora 40 release if possible, > which will also give us a better chance to document it so the small amount of > impacted end-users wrt v7-specific things can prepare for it. > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
